Conformité NF525 — Certifier votre logiciel de caisse contre la fraude TVA

#La norme NF525 — Obligation légale depuis le 1er janvier 2018

L'article 88 de la loi de finances pour 2016 (n° 2015-1785 du 29 décembre 2015) a introduit une obligation nouvelle dans le Code général des impôts : depuis le 1er janvier 2018, tout assujetti à la TVA qui enregistre les règlements de ses clients via un logiciel de caisse ou un système de gestion POS doit utiliser un logiciel satisfaisant à des conditions d'inaltérabilité, de sécurisation, de conservation et d'archivage des données. Cette obligation est codifiée à l'article 286 I-3° bis du CGI et précisée par le BOFiP (BOI-TVA-DECLA-30-10-30).

Qui est concerné ? Toute entreprise ou professionnel assujetti à la TVA dès lors qu'il utilise un logiciel pour enregistrer les paiements de clients : restaurateurs, hôteliers, retailers, prestataires de services, e-commerçants avec point de vente physique, stations-service, traiteurs, bars, brasseries, discothèques — la liste est non limitative. L'obligation ne dépend pas du chiffre d'affaires, de la taille de l'entreprise, ni du secteur d'activité, uniquement du fait d'être assujetti à la TVA et d'utiliser un logiciel pour ces enregistrements. Les micro-entreprises bénéficiant de la franchise en base de TVA (article 293 B CGI) sont exemptées. Les entreprises qui n'acceptent que des espèces sans logiciel sont également hors scope — mais cette situation est devenue marginale.

Deux voies de conformité sont acceptées par la DGFiP. La première est la certification AFNOR NF 525 : le logiciel a été soumis à un organisme certificateur accrédité qui a vérifié et certifié le respect des quatre conditions. L'éditeur peut alors délivrer à ses clients un certificat de conformité. La seconde est l'attestation individuelle délivrée par l'éditeur du logiciel sous sa propre responsabilité, sur un modèle fourni par la DGFiP, attestant que le logiciel satisfait aux quatre conditions. L'attestation individuelle est suffisante légalement mais expose l'éditeur en cas de constat ultérieur de non-conformité : il a certifié sous sa propre responsabilité ce qui s'avère inexact.

#Les 4 conditions NF525 — Analyse technique détaillée

#Condition 1 — Inaltérabilité des données

Une transaction enregistrée dans le logiciel de caisse ne peut plus être modifiée ni supprimée après sa clôture. Techniquement, cela impose un mécanisme de protection cryptographique des enregistrements : la solution standard est le hash chaining — chaque transaction génère un hash (SHA-256 minimum exigé) incluant le hash de la transaction précédente, formant une chaîne brisée si l'on tente de modifier ou supprimer un enregistrement. En base de données, cela se traduit par des triggers qui interdisent tout UPDATE ou DELETE sur les tables de transactions clôturées, une numérotation séquentielle continue sans trou (un gap dans la séquence est en lui-même un signal d'altération), et un audit trail de toute tentative de modification.

Erreur fréquente observée : les corrections administratives (erreur de saisie, remboursement partiel) sont gérées par modification directe de la transaction d'origine plutôt que par une transaction corrective liée. C'est la non-conformité la plus souvent relevée lors de nos audits, y compris sur des logiciels commerciaux répandus.

#Condition 2 — Sécurisation par signature numérique

Chaque transaction doit être couverte par une signature numérique qui garantit son authenticité et son intégrité depuis l'enregistrement. Les deux approches acceptées sont le HMAC (Hash-based Message Authentication Code) avec une clé secrète stockée de manière sécurisée, ou la signature asymétrique (RSA, ECDSA) avec une infrastructure à clé publique. La signature doit être vérifiable a posteriori par la DGFiP — l'auditeur fiscal doit pouvoir vérifier la chaîne de signatures pour n'importe quelle période.

Points de vérification Nehos : l'algorithme utilisé (MD5 et SHA-1 sont considérés comme obsolètes et insuffisants — SHA-256 minimum), la sécurisation des clés (stockage en dehors de la base de données principale, rotation prévue sans rupture de la chaîne), et la complétude de la couverture (toutes les transactions, y compris les annulations, les remboursements, les transactions de formation, doivent être signées).

#Condition 3 — Conservation sur 6 ans

Les données enregistrées doivent être conservées pendant 6 ans minimum à compter de la date de l'enregistrement, dans un format qui garantit leur non-altérabilité sur toute la durée d'archivage. Cette condition soulève des questions pratiques pour les éditeurs SaaS dont les clients peuvent résilier : que se passe-t-il pour les archives après résiliation ? Le contrat doit prévoir un mécanisme d'export et de remise des archives à l'exploitant.

Points techniques : les archives ne doivent pas être stockées dans un système qui permet leur suppression administrative (corbeille, purge programmée, archivage avec destruction différée). Nehos vérifie la politique de rétention réelle en base de données, les logs de suppression, et la procédure documentée de réponse à une réquisition DGFiP.

#Condition 4 — Archivage par clôtures périodiques

Le logiciel doit générer automatiquement un certificat de clôture journalier, mensuel et annuel. Chaque certificat contient le total des transactions de la période, le hash de clôture de la chaîne, la date et l'heure de génération. La DGFiP peut demander à consulter n'importe quel certificat de clôture pour n'importe quelle journée des 6 dernières années — le logiciel doit être capable de les produire instantanément.

Erreur fréquente : la clôture journalière n'est pas automatisée (nécessite une action manuelle de l'opérateur) et n'est donc pas systématiquement effectuée. Un jour sans clôture crée un certificat manquant, ce qui constitue une non-conformité documentée. Nehos vérifie les logs de génération des certificats sur les 12 derniers mois pour quantifier le taux de clôtures manquantes.

#Audit NF525 Nehos — 5 à 10 jours de diagnostic

Notre processus d'audit est structuré en quatre temps. Jour 1-2 : collecte documentaire et revue d'architecture. On demande à l'éditeur ou à l'équipe IT interne le schéma de base de données, le code source du module de caisse (ou accès en revue de code), la documentation technique existante sur la conformité NF525, et les derniers certificats de clôture générés. Jours 3-5 : reverse engineering et tests. On analyse le code de traitement des transactions pour vérifier l'implémentation de la chaîne de hash, on teste les triggers de protection en base de données, on vérifie les algorithmes de signature utilisés, on simule une demande DGFiP (production de certificats pour des périodes passées). Jours 6-8 : gap analysis et qualification des risques. Chaque écart identifié est qualifié en trois niveaux : critique (non-conformité certaine, amende certaine en cas de contrôle — exemple : absence totale de hash chaining), majeur (risque élevé, mise en conformité urgente — exemple : algorithme de hachage obsolète MD5), mineur (risque modéré, bonnes pratiques à améliorer — exemple : documentation insuffisante des clôtures). Jours 9-10 : rapport et plan de remédiation. Le rapport livré comporte le détail des findings par condition NF525, le niveau de risque global, un plan de remédiation priorisé avec estimations de charge par item, et une recommandation sur la voie de conformité (attestation individuelle ou certification AFNOR NF 525 selon le profil de l'éditeur).

Sur les projets avec contrainte de délai (contrôle DGFiP en cours ou signalé), Nehos peut mobiliser en 48h et produire un rapport préliminaire en 5 jours.

#Cas de non-conformité fréquents — Les 8 erreurs techniques les plus observées

Sur les missions d'audit NF525 conduites depuis 2022, voici les huit non-conformités que nous rencontrons le plus souvent, par ordre de fréquence décroissante.

(1) Corrections administratives brisant la chaîne de hash. La fonction de correction d'une transaction erronée (erreur de saisie, changement de TVA a posteriori) modifie directement l'enregistrement d'origine plutôt que de créer une transaction d'annulation liée. La chaîne de hash est brisée à chaque correction. Niveau de risque : critique.

(2) Numérotation séquentielle non continue. Des gaps existent dans la séquence des numéros de transaction — souvent à cause de transactions de test supprimées, de transactions d'initialisation non enregistrées dans la séquence principale, ou de bugs de génération de numéro en cas de concurrent access sur des terminaux multi-caisses. Niveau de risque : majeur.

(3) Clôtures journalières non automatisées. La clôture de caisse nécessite une action manuelle (bouton « clôture du jour ») que les opérateurs n'effectuent pas systématiquement. Des journées entières sans certificat de clôture, constatées a posteriori sur les logs. Niveau de risque : majeur.

(4) Format des archives incomplet. Le fichier d'archive généré lors des clôtures ne contient pas tous les champs requis par le référentiel NF525 : total HT par taux de TVA, total TTC, détail des modes de paiement, hash de clôture chaîné. Niveau de risque : majeur.

(5) Algorithme de signature obsolète. La chaîne de signatures utilise MD5 ou SHA-1, deux algorithmes considérés comme cryptographiquement insuffisants en 2026 et non conformes aux exigences minimales du référentiel NF525 (SHA-256 minimum). Niveau de risque : critique si MD5, majeur si SHA-1.

(6) Multi-terminaux sans numérotation synchronisée. Sur les établissements avec plusieurs caisses (restaurant multi-salle, point de vente multi-caisse), chaque terminal génère sa propre séquence de numéros sans coordination — les séquences se recoupent ou créent des doublons. Non-conformité structurelle sur la condition d'inaltérabilité. Niveau de risque : critique.

(7) Transactions d'annulation non liées à l'original. Les remboursements et annulations sont enregistrés comme des transactions indépendantes sans référence à la transaction d'origine, rendant impossible la reconstitution du parcours complet par la DGFiP. Niveau de risque : majeur.

(8) Architecture multi-établissements avec chaînes de hash non liées. Un groupe avec 30 établissements utilisant un POS centralisé mais des chaînes de hash indépendantes par site, sans mécanisme de consolidation et de vérification croisée. Le risque est que la modification des données d'un établissement dans la base centrale ne soit pas détectable par la vérification de chaîne. Niveau de risque : critique sur l'architecture.

#Mise en conformité — Sprint de remédiation technique

Une fois le rapport d'audit livré, la phase de remédiation démarre selon un périmètre défini conjointement avec l'équipe technique du client ou de l'éditeur du logiciel. La durée typique est de 3 à 12 semaines selon le nombre et la gravité des écarts identifiés.

Nehos intervient selon trois modes selon le contexte client. Mode accompagnement : l'équipe de développement de l'éditeur conduit les corrections, Nehos joue le rôle de référent technique NF525 — revue des choix d'implémentation, validation des développements avant mise en production, tests de conformité sur les environnements de recette. Mode co-développement : l'équipe Nehos travaille en binôme avec les développeurs de l'éditeur, prend en charge les modules les plus critiques (chaîne de hash, génération des certificats) et transfère la connaissance. Mode développement indépendant : l'éditeur original n'est plus disponible (logiciel abandonné, prestataire injoignable) ou n'est pas en mesure de conduire les modifications dans les délais requis — Nehos développe les correctifs directement dans le code source.

Livrable systématique en fin de remédiation : une suite de tests automatisés NF525 (tests unitaires sur chaque condition, tests d'intégration simulant un audit DGFiP) intégrée dans la CI/CD du projet, pour garantir que les futures évolutions du logiciel ne cassent pas la conformité.

#Secteurs concernés — Restauration, Hôtellerie, Retail

#Restauration et hôtellerie

Le secteur le plus exposé, avec des POS complexes (multi-salle, multi-caisse, multi-établissements) et des besoins fréquents de corrections de commande (modification d'addition, offerts, erreurs de saisie) qui créent par nature des risques sur la condition d'inaltérabilité. Les groupes de restauration rapide avec 20+ établissements en franchise centralisent souvent leur POS, ce qui peut créer des situations de non-conformité architecturale de niveau critique (erreur n°8 ci-dessus).

Cas PMS hôtelier : les hôtels qui utilisent un PMS (Opera Cloud, Mews, Clock PMS, Protel) pour facturer leurs prestations (restauration, bar, spa) doivent vérifier que le module de facturation du PMS satisfait aux quatre conditions NF525. Ce n'est pas systématiquement le cas — certains PMS délèguent la conformité à un module POS tiers sans assurer la cohérence de la chaîne de hash entre les deux systèmes.

#E-commerce omnicanal

Les retailers avec des ventes en ligne et des points de vente physiques doivent s'assurer que les deux canaux sont couverts. La question se pose en particulier quand le POS magasin et la plateforme e-commerce sont des systèmes distincts : l'obligation NF525 s'applique aux deux dès lors qu'ils enregistrent des paiements de clients assujettis à la TVA. Cas non-évident : les plateformes SaaS e-commerce (Shopify, Prestashop, WooCommerce) en mode SaaS hébergé hors France — la DGFiP considère que l'obligation s'applique à l'assujetti français utilisateur de la plateforme, quelle que soit la localisation du serveur.

#Services professionnels et facturation intégrée

Cabinets médicaux utilisant un logiciel de gestion qui enregistre les paiements patients, avocats, architectes, agences événementielles — dès lors qu'un logiciel enregistre les paiements client, la NF525 s'applique. Les logiciels de facturation généralistes (Sage, EBP, Cegid) ont généralement publié des attestations individuelles pour leurs versions récentes, mais les versions antérieures ne sont pas nécessairement couvertes. Vérifier la date d'application de l'attestation de l'éditeur.

#Attestation individuelle vs certification AFNOR NF525

Deux voies légales, deux niveaux de garantie. La certification AFNOR NF 525 est l'étalon de référence : un organisme certificateur accrédité par le COFRAC a audité le logiciel selon le référentiel NF 525, vérifié les quatre conditions, et délivré un certificat officiel. L'éditeur peut fournir à ses clients une copie de ce certificat — c'est le document le plus solide pour répondre à un contrôle DGFiP. La certification coûte entre 15 000 et 480 000 € selon l'organisme certificateur et la complexité du logiciel, et prend 3 à 6 mois. Elle doit être renouvelée à chaque évolution majeure du logiciel qui impacte les fonctions NF525.

L'attestation individuelle est publiée par l'éditeur sous sa propre responsabilité, sans vérification par un tiers accrédité. Elle est légalement suffisante pour l'entreprise utilisatrice (qui peut la produire lors d'un contrôle DGFiP). Mais elle expose l'éditeur en cas de non-conformité constatée a posteriori : il a attesté sous sa responsabilité la conformité d'un logiciel qui ne l'était pas. Pour un éditeur SaaS dont le logiciel est utilisé par des dizaines ou centaines d'établissements assujettis, la responsabilité cumulative en cas de non-conformité avérée est très significative.

Recommandation Nehos : pour les éditeurs de logiciels de caisse multi-clients (restauration, retail, services), la certification AFNOR est l'investissement qui protège durablement la responsabilité de l'éditeur et renforce la confiance des clients. L'attestation individuelle est acceptable pour les développements internes (une entreprise qui a développé son propre POS pour ses propres établissements), sous réserve que l'audit technique préalable soit rigoureux. Nehos accompagne les deux parcours.

#DGFiP 2026 — Contrôles renforcés et risque fiscal

Depuis 2024, la DGFiP a intégré la vérification NF525 à ses procédures de contrôle fiscal des entreprises des secteurs de la restauration, du commerce de détail et des services. En pratique, lors d'un contrôle fiscal standard (Examen de Comptabilité ou Vérification de Comptabilité), le vérificateur demande désormais systématiquement la production de l'attestation NF525 (certificat de l'organisme accrédité ou attestation individuelle de l'éditeur) et peut demander à vérifier techniquement la conformité du logiciel en production.

La sanction prévue à l'article 1770 duodecies du CGI est de 120 000 € par logiciel non conforme. Ce montant s'applique par établissement et par contrôle — pour une chaîne de restauration de 28 établissements, l'exposition totale est de3 360 000 €. Il n'y a pas de plafond global prévu par les textes. Au-delà de l'amende, la DGFiP peut considérer que l'absence d'inaltérabilité des enregistrements de caisse crée un risque de minoration du chiffre d'affaires et de la TVA collectée — fondant une procédure de reconstitution du chiffre d'affaires (article L. 73 du LPF) avec rappel de TVA sur les 3 ou 6 dernières années selon les modalités du contrôle, majorations de 40 % (manquement délibéré) ou 80 % (manœuvres frauduleuses), et intérêts de retard de 0,20 % par mois.

En 2026, l'URSSAF conduit également des rapprochements avec les données DGFiP sur certains secteurs à risque (restauration, bâtiment) — une non-conformité NF525 documentée peut alimenter un contrôle URSSAF parallèle.

#Méthodologie de déploiement

Notre mission type NF525 suit cinq phases séquentielles avec des points de décision clairs. Phase 0 — Cadrage (2 jours, gratuit sous NDA) : qualification du logiciel concerné, de l'architecture technique (on-premise, SaaS hébergé France, SaaS hébergé hors France), du nombre d'établissements et de terminaux, du contexte de risque DGFiP (contrôle en cours ou préventif). Phase 1 — Audit (5-10 jours) : diagnostic complet des quatre conditions NF525, rapport de gap analysis avec classification des écarts (critique / majeur / mineur), recommandation sur la voie de mise en conformité (attestation individuelle ou certification AFNOR). Phase 2 — Remédiation (3-12 semaines selon gaps) : corrections techniques des non-conformités identifiées, tests d'intégrité, suite de tests automatisés NF525 intégrée à la CI/CD. Phase 3 — Certification ou attestation (2-6 semaines) : si certification AFNOR, accompagnement de la soumission au certificateur et suivi jusqu'à l'émission du certificat ; si attestation individuelle, validation du document et support à la publication. Phase 4 — Maintien en condition de conformité : revue annuelle, procédure d'alerte en cas d'évolution du logiciel impactant la conformité NF525, mise à jour de la certification ou de l'attestation.

#ROI et risque évité — Cas chaîne de restauration 28 établissements

Contexte : chaîne de restauration rapide française (anonymisée sous NDA), 28 établissements en propre, POS propriétaire développé en interne en 2019. En 2025, la direction financière identifie le risque NF525 lors d'un rapprochement avec un contrôle fiscal d'un concurrent du secteur. Mission Nehos : audit + remédiation + publication de l'attestation individuelle.

Résultats de l'audit (7 jours) : 3 non-conformités critiques (chaîne de hash brisée par les corrections de commande, multi-terminaux sans numérotation synchronisée, algorithme MD5), 2 majeures (clôtures journalières non automatisées sur 3 établissements, format des archives incomplet sur le total HT par taux), 1 mineure. Remédiation : 6 semaines de sprint technique (équipe Nehos en co-développement avec l'équipe IT interne), correction des 3 critiques et des 2 majeures, suite de tests automatisés NF525 intégrée dans le pipeline GitLab CI.

Résultat financier : risque évité de 120 000 € × 28 =3 360 000 € d'amende minimale, plus le risque de reconstitution de CA qui n'est pas chiffrable a priori mais représente plusieurs années de TVA collectée sur 28 établissements. Investissement total mission Nehos :608 000 € HT. ROI calculé sur la seule amende minimale évitée : 5,5 x. L'attestation individuelle publiée a également permis de sécuriser le renouvellement du contrat d'un franchisé qui exigeait la preuve de conformité NF525 dans son audit fournisseurs.

#Tarification — 15 à 720 k€ HT

Trois forfaits selon le périmètre d'intervention. Audit seul (sans remédiation) : 15 à 352 k€ HT, inclut les 5-10 jours de diagnostic, le rapport complet avec gap analysis classifié par niveau de risque, le plan de remédiation chiffré et le conseil sur la voie de mise en conformité. Adapté aux DSI qui souhaitent qualifier le risque avant de décider de la suite. Audit + remédiation jusqu'à l'attestation individuelle : 22 à 608 k€ HT selon le nombre et la gravité des écarts. Inclut la remédiation technique des non-conformités, la suite de tests automatisés et l'accompagnement à la publication de l'attestation individuelle. Délai typique : 6 à 12 semaines. Mission complète jusqu'à la certification AFNOR NF 525 : 38 à 720 k€ HT, hors frais du certificateur accrédité (15 000 à480 000 € en plus, payés directement à l'organisme). Recommandé pour les éditeurs SaaS multi-clients et les groupes avec plus de 20 établissements. Délai : 12 à 20 semaines.

Pour les groupes multi-établissements avec plus de 50 sites, nous étudions des conditions spécifiques en fonction du volume et de la complexité de l'architecture. Estimation précise en 30 minutes sur RDV : [Calendly conformité NF525](https://calendly.com/raphael-poirier_/decouverte15min-nehos-groupe