---
title: NF525 : loi, certification et architecture d'un logiciel de caisse sécurisé
source: https://synapx.fr/blog/nf525-logiciel-caisse-securise/
date: 2026-07-15
category: Facturation électronique
site: SynapxLab
---

# NF525 : loi, certification et architecture d'un logiciel de caisse sécurisé

**NF525 est souvent présentée comme “la norme obligatoire des caisses”. Cette formule est pratique, mais juridiquement inexacte.** La loi française n'impose ni une marque commerciale ni un algorithme particulier : elle exige qu'un logiciel ou système de caisse garantisse l'**inaltérabilité**, la **sécurisation**, la **conservation** et l'**archivage** des données. Ces quatre conditions forment l'acronyme **ISCA**.

La certification **NF525** est l'une des voies permettant de faire contrôler ces garanties par un tiers. Et, depuis le **21 février 2026**, l'attestation individuelle de l'éditeur est de nouveau admise comme autre mode de preuve. Cette précision est importante : beaucoup de pages publiées en 2025 annoncent encore, à tort, la disparition définitive de l'attestation au 1er septembre 2026.

Ce dossier repart de l'histoire de la lutte contre la fraude à la TVA, explique ce qu'un logiciel doit réellement protéger, puis ouvre le capot : tickets immuables, contre-écritures, chaînes d'empreintes, journal d'événements, clôtures Z, totaux perpétuels et archives vérifiables. La dernière partie montre comment transformer ces principes en un dossier de preuves exploitable, sans confondre travail de conformité et certification déjà obtenue.

> **Situation vérifiée au 15 juillet 2026 :** le respect des conditions ISCA peut être justifié par un **certificat délivré par un organisme accrédité** ou par une **attestation individuelle de l'éditeur** conforme au modèle de l'administration. NF525 reste une certification tierce reconnue ; elle n'est plus l'unique route envisagée par les textes.

## NF525 en cinq réponses

| Question | Réponse courte |
|---|---|
| Quel est le bon sigle ? | **NF525**, et non FN525. |
| Est-ce une loi ? | Non. C'est une certification fondée sur un référentiel privé ; la loi impose les quatre conditions ISCA. |
| Est-elle obligatoire ? | La **preuve de conformité** est obligatoire pour les systèmes concernés ; NF525 est une voie de certification, pas le seul mode de preuve depuis février 2026. |
| Un hash suffit-il ? | Non. Le hash n'est qu'une pièce d'un système technique, documentaire et organisationnel. |
| Est-ce la même chose que Factur-X ? | Non. NF525 traite l'encaissement et sa traçabilité ; Factur-X traite le format d'une facture électronique. |

## Pourquoi la caisse est devenue un sujet fiscal

Une caisse mécanique imprimait ses opérations sur un rouleau. Une caisse informatisée apporte des fonctions infiniment plus riches : catalogue, remises, annulations, statistiques, export comptable et synchronisation avec un ERP. Elle introduit aussi une possibilité nouvelle : modifier après coup les recettes enregistrées sans laisser la rature visible qu'aurait portée un livre papier.

Le scénario de fraude classique n'exige pas de casser une banque. Il suffit qu'un logiciel permette de supprimer une vente en espèces, de recalculer les totaux puis de présenter une comptabilité apparemment cohérente. Les recettes disparaissent, avec la TVA correspondante. La réponse réglementaire consiste donc moins à “interdire la modification d'un fichier” — impossible à garantir absolument pour un administrateur — qu'à rendre chaque modification **interdite fonctionnellement ou détectable et traçable**.

La chronologie française explique plusieurs confusions encore présentes en ligne :

```mermaid
flowchart LR
    A["29 décembre 2015<br>loi anti-fraude à la TVA"] --> B["1er janvier 2018<br>obligation applicable"]
    B --> C["16 février 2025<br>suppression de l'attestation éditeur"]
    C --> D["2025<br>mesures transitoires vers la certification"]
    D --> E["21 février 2026<br>attestation éditeur rétablie"]
    E --> F["25 mars 2026<br>BOFiP et modèle mis à jour"]
```

- La loi de finances pour 2016 a posé le principe de sécurisation des logiciels et systèmes de caisse, applicable depuis le **1er janvier 2018**.
- La loi de finances pour 2025 a supprimé l'attestation de l'éditeur à compter du **16 février 2025**. Un calendrier transitoire avait ensuite conduit à annoncer une certification obligatoire au 1er septembre 2026.
- L'[article 125 de la loi de finances pour 2026](https://www.legifrance.gouv.fr/jorf/article_jo/JORFARTI000053508893) a rétabli l'attestation individuelle à compter du **21 février 2026**.
- Le [BOFiP mis à jour le 25 mars 2026](https://bofip.impots.gouv.fr/bofip/10691-PGP.html/identifiant=BOI-TVA-DECLA-30-10-30-20260325) confirme que certificat et attestation sont deux modes de preuve alternatifs.

Le changement de 2026 n'a supprimé aucune exigence technique. Il a modifié la manière de **prouver** que ces exigences sont respectées. Une attestation engage la responsabilité de l'éditeur ; ce n'est ni une déclaration publicitaire générale, ni un bouton “conforme” ajouté dans le logiciel.

## Qui est réellement concerné ?

Le dispositif vise les assujettis à la TVA qui effectuent des opérations avec des clients particuliers et enregistrent leurs règlements au moyen d'un logiciel ou d'un système de caisse. Il ne crée pas d'obligation générale d'acheter une caisse informatisée : un professionnel qui ne mémorise pas ses encaissements dans un tel système n'entre pas dans le dispositif pour ce seul motif.

Quelques repères issus de la doctrine fiscale :

- une entreprise qui réalise **exclusivement du B2B** est hors du dispositif de caisse, puisque ses opérations donnent obligatoirement lieu à facturation ;
- une activité mixte **B2B et B2C** entre dans le champ pour sa fonction d'encaissement ;
- le logiciel reste concerné quel que soit le paiement enregistré : espèces, carte, chèque, virement ou prélèvement ;
- une caisse en ligne, une borne, un automate ou une balance qui mémorise les règlements peut être concerné ;
- dans un ERP multifonction, seule la **fonction de caisse et d'encaissement** doit répondre à cette obligation spécifique ;
- les assujettis en **franchise en base de TVA**, ceux soumis au remboursement forfaitaire agricole et ceux qui réalisent exclusivement des opérations exonérées font partie des exclusions prévues par le texte ;
- le BOFiP prévoit également un tempérament étroit lorsque **tous** les paiements passent directement par certains établissements de crédit répondant aux conditions précisées par l'administration.

La qualification dépend donc du flux réel, pas du nom du produit. Renommer une fonction “paiement”, “commande” ou “facturation” ne change rien si elle mémorise extra-comptablement le règlement d'un particulier.

### Que risque l'entreprise en cas de défaut de preuve ?

Au **15 juillet 2026**, l'[article 1770 duodecies du CGI](https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000053546759) prévoit une amende de **7 500 euros par logiciel ou système de caisse concerné** lorsqu'un assujetti ne peut pas justifier que son outil respecte les quatre conditions. Après l'application de l'amende, il dispose de **soixante jours** pour se mettre en conformité ; passé ce délai, l'amende peut être appliquée de nouveau.

La preuve ne doit surtout pas être fabriquée pour le contrôle. Le modèle BOFiP rappelle qu'une fausse attestation expose son auteur et son utilisateur conscient aux sanctions pénales du faux : jusqu'à **trois ans d'emprisonnement et 45 000 euros d'amende**. Le sujet porte donc autant sur l'authenticité du document que sur les garanties du logiciel.

## ISCA : les quatre garanties que la loi attend

### I — Inaltérabilité

La donnée d'origine doit rester accessible. Une vente validée ne se réécrit pas silencieusement et ne disparaît pas. Si elle doit être corrigée, la correction prend la forme d'une nouvelle opération positive ou négative, elle-même datée, identifiée et protégée.

Dans une caisse bien conçue :

- le brouillon reste modifiable avant validation ;
- le ticket validé devient un objet fiscal scellé ;
- une annulation produit un **contre-ticket** ou un avoir qui neutralise l'opération sans effacer l'original ;
- la suppression directe des tickets, paiements et clôtures est refusée ;
- une tentative de modification hors du parcours normal doit être détectable.

L'inaltérabilité ne signifie donc pas “aucune correction”. Elle signifie **aucune correction invisible**.

### S — Sécurisation

Le système doit préserver l'intégrité des enregistrements et des corrections. La doctrine ne prescrit pas un algorithme unique : chaînage, signature électronique ou procédé fiable équivalent peuvent être employés.

La sécurisation porte aussi sur la piste d'audit : qui a ouvert une session, consenti une remise, annulé un ticket, réimprimé un justificatif, ouvert le tiroir ou généré une clôture ? Un mode école ou test doit être clairement distingué par une mention telle que **FACTICE** ou **SIMULATION**, et l'opérateur responsable doit rester identifiable.

### C — Conservation

Les données élémentaires, leurs preuves d'intégrité et les traces associées doivent être conservées pendant le délai fiscal, généralement **six ans**. Conserver uniquement un total quotidien ou le ticket Z ne suffit pas : l'administration doit pouvoir retrouver les lignes ayant produit ce total.

Pour une caisse, le BOFiP demande des clôtures **journalière, mensuelle et annuelle** — ou par exercice — cumulatives et impératives, avec :

- le total de la période ;
- un grand total cumulatif ;
- un **total perpétuel** qui ne revient jamais à zéro lors d'une simple mise à jour du logiciel ;
- les données de détail et de traçabilité ayant servi aux calculs.

### A — Archivage

Archiver ne consiste pas à copier la base pour pouvoir redémarrer après une panne. Une sauvegarde restaure le service ; une archive fiscale **fige un état**, lui donne une date certaine et permet d'en contrôler ultérieurement l'intégrité.

L'archive doit notamment :

- être produite selon une périodicité au maximum annuelle ou par exercice ;
- rester lisible dans un **format ouvert**, même après changement de logiciel ;
- être accompagnée d'une notice explicative en français ;
- contenir ou accompagner les preuves permettant de vérifier son intégrité ;
- laisser une trace de sa génération ;
- précéder toute purge éventuelle, sans jamais faire disparaître les totaux cumulatifs qui doivent rester en ligne.

> **Sauvegarde, conservation et archivage sont trois notions différentes.** Une réplication de base n'est pas une archive fiscale ; une archive annuelle ne remplace pas les données de détail à conserver ; un hash de fichier n'est utile que si sa valeur de référence et le processus de production sont eux-mêmes protégés.

## Comment fonctionne une chaîne d'empreintes

Une empreinte cryptographique transforme un contenu en une valeur de taille fixe. Si un caractère du contenu change, l'empreinte change. Pour relier les écritures, chaque nouvelle empreinte inclut celle de l'écriture précédente :

```text
H0 = ancre initiale
H1 = SHA-512(données_du_ticket_1 || H0)
H2 = SHA-512(données_du_ticket_2 || H1)
H3 = SHA-512(données_du_ticket_3 || H2)
```

```mermaid
flowchart LR
    A["Ticket 1<br>données canoniques"] --> H1["H1"]
    Z["Ancre H0"] --> H1
    B["Ticket 2<br>données canoniques"] --> H2["H2"]
    H1 --> H2
    C["Ticket 3<br>données canoniques"] --> H3["H3"]
    H2 --> H3
    H3 --> V["Contrôle : recalcul<br>et comparaison"]
```

Une altération ancienne casse le recalcul à cet endroit et, par propagation, la continuité attendue. Cette technique apporte une preuve d'intégrité utile, à condition de respecter plusieurs règles :

1. la représentation des données doit être **canonique** — mêmes champs, même ordre, mêmes formats de date et de montant ;
2. deux ventes concurrentes ne doivent pas partir de la même tête de chaîne ; la numérotation et le hash doivent être sérialisés sous verrou ;
3. l'ancre ou la tête de chaîne ne doit pas pouvoir être remplacée discrètement ;
4. l'événement, l'auteur, l'horodatage et la version du logiciel doivent rester traçables ;
5. un contrôle indépendant doit pouvoir recalculer la chaîne ;
6. les archives et clôtures doivent prolonger cette preuve dans le temps.

Ce mécanisme est parfois appelé abusivement “blockchain”. Il n'y a pourtant ni réseau distribué, ni consensus entre nœuds indépendants. Il s'agit d'un **journal chaîné par empreintes**. Et il faut conserver une limite en tête : un administrateur capable de modifier toutes les données, de recalculer toute la chaîne et de remplacer toutes les ancres peut fabriquer un nouvel ensemble cohérent. La conformité repose donc sur plusieurs couches, pas sur le seul SHA-512.

## Le cycle fiscal d'une vente

La bonne architecture sépare nettement ce qui est encore commercial de ce qui est devenu fiscal :

```mermaid
flowchart TD
    A["Panier / brouillon<br>modifiable"] --> B["Validation atomique"]
    B --> C["Numéro séquentiel<br>+ ticket scellé + hash"]
    C --> D["Paiements et JET<br>journalisés"]
    C --> E{"Correction ?"}
    E -->|"non"| F["Clôture journalière Z"]
    E -->|"oui"| G["Contre-ticket<br>l'original reste visible"]
    G --> F
    F --> H["Clôtures mensuelle<br>et annuelle"]
    H --> I["Archive ouverte<br>+ preuve d'intégrité"]
```

La validation doit idéalement être **atomique** : soit le numéro, le ticket, ses lignes, ses paiements, le hash et l'événement d'audit sont tous enregistrés, soit aucun ne l'est. Cette propriété évite les numéros consommés sans ticket, les paiements orphelins et les chaînes partiellement écrites.

Le traitement hors ligne demande une attention particulière. Une tablette peut préparer une file locale, mais attribuer en autonomie des numéros fiscaux à plusieurs terminaux augmente le risque de collision, de trou et de divergence d'horloge. Une stratégie prudente conserve les écritures comme provisoires hors ligne puis réalise la validation fiscale, la numérotation et le chaînage lors d'une resynchronisation contrôlée.

## Loi, attestation, certificat et NF525 : ne plus les confondre

| Élément | Ce qu'il représente | Qui le porte | Effet |
|---|---|---|---|
| **Article 286 du CGI et BOFiP** | L'obligation ISCA et son champ d'application | Législateur et administration fiscale | Définit ce qui doit être garanti |
| **Attestation individuelle éditeur** | Un mode de preuve conforme au modèle BOI-LETTRE-000242 | Éditeur, puis utilisateur pour le second volet | Engage la responsabilité de l'éditeur et couvre un périmètre/version précis |
| **Certificat d'organisme accrédité** | Un autre mode de preuve, fondé sur un audit tiers | Organisme certificateur accrédité | Apporte une évaluation indépendante du produit |
| **NF525** | La marque et le référentiel de certification des logiciels de gestion d'encaissement développés par INFOCERT avec AFNOR Certification | INFOCERT / AFNOR Certification | Une voie de certification tierce couvrant ISCA et des exigences complémentaires |
| **Certification selon le référentiel LNE** | Une autre certification des systèmes d'encaissement | Organisme accrédité compétent pour ce référentiel | Une autre voie de certificat admise si elle atteste les conditions légales |

Le [modèle BOI-LETTRE-000242](https://bofip.impots.gouv.fr/bofip/10692-PGP.html/identifiant=BOI-LETTRE-000242-20260325) comporte désormais deux volets : l'éditeur décrit le logiciel, la version et le périmètre couverts ; l'entreprise utilisatrice complète sa propre identification et son usage. Une mention générique dans des conditions générales ne remplace pas cette attestation individuelle.

Une évolution majeure qui touche les paramètres ayant un impact sur ISCA impose de renouveler la preuve correspondante. Il faut donc traiter le **versionnage fiscal** comme une fonction du produit : savoir quelle version est installée, quelles modifications affectent le périmètre certifié ou attesté, et quels tests ont été exécutés avant livraison.

## Ce qu'un audit de certification regarde réellement

Un audit ne se limite pas à lancer une requête qui recalcule trois hashes. Le certificateur examine le produit et la manière dont l'éditeur le maintient. Selon le référentiel et le périmètre, le dossier doit notamment rendre démontrables :

- l'architecture et le périmètre exact de la fonction d'encaissement ;
- les règles d'inaltérabilité, les corrections et les interdits ;
- la numérotation, les clôtures, les cumuls et le journal des événements ;
- les formats d'archive, la restitution et la politique de conservation ;
- les droits, la traçabilité des opérateurs et les modes école/test ;
- la gestion des versions majeures et mineures ;
- les changements du code et les procédures de non-régression ;
- les manuels utilisateur et d'exploitation ;
- les tests d'altération, de panne, de concurrence, d'annulation et de restauration ;
- la capacité de l'équipe à présenter des preuves cohérentes, reproductibles et datées.

C'est pourquoi “le code semble conforme” ne vaut pas certification. À l'inverse, la documentation seule ne compense pas une suppression réellement possible en base. Le dossier le plus solide relie chaque exigence à une implémentation, à un test et à une preuve consultable.

## Du code au dossier de preuves

Une architecture sérieuse ne devient démontrable que lorsque ses mécanismes sont reliés à des preuves reproductibles. Le dossier ne doit pas seulement décrire ce que le logiciel est censé faire ; il doit montrer où la règle est appliquée, comment elle est testée et quel résultat un auditeur peut contrôler.

### Une piste d'audit exploitable

Une piste d'audit peut s'appuyer sur un journal append-only ou sur des tables d'historique. Chaque écriture devrait conserver au minimum :

- l'identifiant de la donnée d'origine ;
- le type d'opération — ajout, mise à jour, correction ou annulation ;
- l'utilisateur ou le processus associé ;
- la date et l'heure ;
- l'empreinte de chaînage ;
- les champs concernés par l'opération ;
- les valeurs nécessaires à la reconstitution de l'historique.

Une fonction de contrôle doit recalculer la continuité et signaler les ruptures. Ce dispositif constitue une brique transversale, mais une caisse exige aussi des gardes métier : un ticket fiscal ne doit pas redevenir un brouillon, ses montants ne doivent pas être réécrits et sa correction doit créer une opération inverse.

### La matrice centrale du dossier

La pièce la plus utile relie chaque attente à des éléments vérifiables :

| Exigence | Mécanisme attendu | Test de preuve | Élément à remettre |
|---|---|---|---|
| Ticket fiscal | Numéro séquentiel attribué atomiquement | Deux validations concurrentes ne produisent ni doublon ni collision | Spécification de numérotation et journal de test |
| Immuabilité | Champs fiscaux scellés et suppression refusée | Tentative de modification ou suppression après validation | Résultat du test et trace de l'échec |
| Correction | Contre-ticket conservant le lien avec l'original | Annulation répétée, avoir partiel ou total | Ticket initial, contre-opération et historique |
| Intégrité | Chaîne d'empreintes et contrôle indépendant | Altération volontaire d'une ancienne ligne | Rapport indiquant la rupture exacte |
| Traçabilité | Journal d'événements append-only | Remise, réimpression, changement d'heure, ouverture de tiroir | Extrait JET daté et expliqué |
| Clôtures | Z journalier et cumuls mensuel/annuel scellés | Rejeu d'une clôture déjà produite | Clôture identique et preuve d'intégrité |
| Cumul | Total perpétuel jamais remis à zéro | Mise à jour ou changement de version | Avant/après avec continuité du compteur |
| Archivage | Format ouvert, notice et empreinte | Lecture sur un environnement distinct | Archive, notice française et contrôle de hash |
| Conservation | Données élémentaires et preuves disponibles six ans | Recherche d'une ancienne transaction | Restitution complète du détail au cumul |
| Mode école | Données séparées et mention FACTICE/SIMULATION | Impression et export d'une vente fictive | Justificatif marqué et opérateur identifié |

### Les scénarios de non-régression indispensables

Le plan de tests doit couvrir les chemins normaux et les tentatives de contournement :

1. valider deux ventes simultanément sur la même caisse ;
2. rejouer deux fois la même requête après une coupure réseau ;
3. tenter de modifier le montant, la date, le numéro ou le hash d'un ticket validé ;
4. annuler une vente puis tenter de l'annuler une seconde fois ;
5. altérer volontairement une ancienne ligne et localiser la rupture de chaîne ;
6. générer les clôtures journalière, mensuelle et annuelle, puis les rejouer ;
7. restaurer une sauvegarde sans perdre la continuité des compteurs ;
8. migrer vers une nouvelle version sans remettre le total perpétuel à zéro ;
9. exporter une archive et la relire sans dépendre de l'application d'origine ;
10. vérifier que le mode formation ne consomme pas de numéro fiscal et reste marqué comme fictif.

Un test vert ne prouve que le comportement couvert par ce test. Il faut donc conserver le code testé, la configuration, la version de la base, le résultat et la date d'exécution. Une suite rejouée après chaque changement fiscal transforme la non-régression en preuve plutôt qu'en promesse.

### Ce qui sépare un socle technique d'une preuve opposable

Le dossier de préparation doit encore franchir des étapes documentaires et administratives :

1. figer le périmètre et la version soumis ;
2. confronter chaque exigence au référentiel à jour de la voie choisie ;
3. produire la matrice **exigence → code → test → preuve** ;
4. formaliser les procédures de versionnage fiscal, d'habilitation, d'exploitation et de restauration ;
5. vérifier visuellement tous les supports, notamment la mention FACTICE/SIMULATION du mode formation ;
6. établir l'attestation conforme au modèle administratif si toutes les conditions sont réellement réunies, ou soumettre le logiciel à l'audit tiers choisi ;
7. remettre à chaque utilisateur le document correspondant exactement à sa version.

Le code, les tests et la documentation constituent un socle de conformité et une préparation à la preuve. Ils ne permettent pas d'annoncer une certification tierce tant que celle-ci n'a pas été délivrée pour la version et le périmètre concernés.

## NF525, Factur-X, e-reporting et FEC : quatre pièces différentes

Ces sujets se rencontrent dans un ERP, mais ils ne répondent pas à la même question :

| Dispositif | Objet principal | Flux typique |
|---|---|---|
| **ISCA / NF525** | Fiabilité et restitution des données d'encaissement | Vente B2C, ticket, règlement, clôture |
| **Factur-X / EN 16931** | Format structuré d'une facture lisible par l'humain et la machine | Facture B2B au format PDF/A-3 + XML |
| **E-reporting** | Transmission à l'administration de données hors e-invoicing domestique et de certaines données de paiement | B2C, international, paiement de services |
| **FEC** | Restitution normalisée des écritures comptables | Contrôle de la comptabilité informatisée |

Une Factur-X valide ne prouve pas que les règlements de caisse sont inaltérables. Un système de caisse conforme ne transforme pas automatiquement un PDF en facture électronique structurée. Et un Z exact ne suffit pas si le FEC oublie le chiffre d'affaires correspondant ou le compte deux fois.

La réforme de la facturation électronique rapproche néanmoins les domaines : les ventes B2C alimentent l'e-reporting, tandis que les ventes B2B relèvent de l'e-invoicing. L'ERP doit donc savoir qualifier l'opération, éviter les doubles écritures et conserver un lien vérifiable entre ticket, paiement, facture éventuelle, clôture et export comptable.

Pour le versant facture, consultez notre [dossier Factur-X, plateformes agréées et e-reporting](/blog/factur-x-comprendre-valider/) ainsi que notre guide [Êtes-vous prêt pour le 1er septembre 2026 ?](/blog/facture-electronique-1er-septembre-2026/).

## Checklist pour l'entreprise utilisatrice

Avant de considérer le sujet clos, une entreprise peut demander à son éditeur :

- Suis-je dans le champ du dispositif au regard de mes clients, de ma TVA et de mes moyens de paiement ?
- Quel est le **nom exact**, le numéro de version et le périmètre de la fonction caisse ?
- Dispose-t-on d'une attestation individuelle conforme au modèle 2026 ou d'un certificat tiers correspondant à cette version ?
- Une annulation conserve-t-elle le ticket d'origine et produit-elle une contre-opération ?
- Les clôtures journalière, mensuelle et annuelle sont-elles disponibles et inaltérables ?
- Le total perpétuel survit-il aux mises à jour ?
- Peut-on exporter les données de détail et les archives dans un format lisible sans l'éditeur ?
- Le mode formation imprime-t-il clairement FACTICE ou SIMULATION ?
- Que devient la preuve après une mise à jour majeure, un changement de caisse ou une migration ?
- Qui conserve les archives pendant six ans et comment leur intégrité est-elle contrôlée ?

Le bon document est celui qui correspond au logiciel réellement utilisé. Une attestation ancienne, un certificat visant une autre édition ou le logo NF affiché sans référence vérifiable ne suffisent pas.

## Checklist pour l'éditeur

Pour l'éditeur, la conformité durable est un processus :

1. cartographier toutes les données de transaction et de règlement ;
2. séparer brouillon, validation fiscale et correction ;
3. rendre atomiques numérotation, enregistrement, paiement, hash et journalisation ;
4. interdire les suppressions et modifications silencieuses, y compris par les routes secondaires ;
5. chaîner et contrôler les tickets, événements et clôtures ;
6. conserver le détail, les cumuls et le total perpétuel ;
7. produire une archive ouverte, documentée et vérifiable ;
8. tester concurrence, panne, rejeu, corruption, restauration et changement de version ;
9. documenter les responsabilités et les habilitations ;
10. geler la version, archiver les résultats et renouveler la preuve lors d'une évolution majeure.

La difficulté n'est pas de calculer un hash. Elle est de garantir qu'**aucun chemin fonctionnel ou technique ne contourne la règle**, puis de pouvoir le démontrer plusieurs années plus tard.

## FAQ

### La certification NF525 est-elle obligatoire ?

La loi n'impose pas la marque NF525 elle-même. Elle impose les quatre conditions ISCA et la détention d'une preuve adaptée. Depuis le 21 février 2026, cette preuve peut être un certificat d'organisme accrédité ou une attestation individuelle de l'éditeur conforme au modèle fiscal.

### Pourquoi voit-on encore partout la date du 1er septembre 2026 ?

Cette date provenait de la période où la loi de finances pour 2025 avait supprimé l'attestation éditeur et où l'administration avait organisé une transition vers la certification exclusive. La loi de finances pour 2026 a rétabli l'attestation avant cette échéance. Une page qui annonce encore une certification exclusivement obligatoire à cette date n'intègre probablement pas la mise à jour du 25 mars 2026.

### Faut-il écrire FN525 ou NF525 ?

La bonne appellation est **NF525**. “NF” désigne la marque NF ; 525 est l'identifiant de la certification consacrée aux logiciels de gestion d'encaissement.

### Une base de données en lecture seule suffit-elle ?

Non. Il faut gérer les corrections, les auteurs, les clôtures, les archives, les versions et la restitution. Une base peut aussi être modifiée par un administrateur : le système doit pouvoir détecter et prouver les altérations, pas seulement masquer un bouton dans l'interface.

### Un certificat couvre-t-il tout l'ERP ?

Pas nécessairement. Dans un logiciel multifonction, le périmètre peut viser la fonction de caisse et d'encaissement. Il faut lire le certificat ou l'attestation : produit, modules, fonctions, version et éventuelles exclusions.

### Quelle différence avec Factur-X ?

Factur-X est un format de facture électronique ; NF525 est une certification relative aux logiciels de gestion d'encaissement. Une même vente peut produire un ticket sécurisé, une facture Factur-X et une écriture comptable, mais chaque objet conserve ses propres règles.

### Comment vérifier qu'un produit est réellement certifié NF525 ?

Demandez la copie du certificat correspondant à la version utilisée et vérifiez sa présence dans le registre du certificateur. Le nom commercial seul ou un logo sur une page de vente ne prouvent ni le périmètre ni la validité du certificat.

## Conclusion

NF525 n'est ni un mot de passe magique, ni une simple fonction de hachage. C'est une démarche de certification construite autour d'une obligation fiscale plus large : conserver une histoire complète, cohérente et vérifiable de chaque encaissement.

Le changement législatif de 2026 redonne aux éditeurs la possibilité d'établir une attestation individuelle. Il ne réduit pas leur responsabilité ; il l'expose davantage. Qu'un produit choisisse l'attestation ou l'audit tiers, le niveau d'exigence technique reste le même : une vente validée ne disparaît pas, une correction laisse une contre-trace, les cumuls ne repartent pas à zéro, les archives restent lisibles et chaque version peut démontrer ce qu'elle garantit.

La prochaine étape n'est jamais d'ajouter le mot “NF525” dans une brochure. C'est de transformer chaque exigence en preuve datée, reproductible et assumée.