Depuis la loi de finances pour 2026, l’attestation éditeur redevient possible pour justifier la conformité d’un logiciel ou système de caisse. Beaucoup de commerçants ont compris le message général : il n’est plus toujours nécessaire de passer par une certification NF525 ou LNE lorsque l’éditeur peut produire une attestation individuelle conforme.

Mais une difficulté reste entière pour les entreprises qui utilisent un logiciel de caisse open source, un outil modifié par un intégrateur, un module relié à un site e-commerce, ou un système développé en interne. Dans ces dossiers, la question n’est pas seulement : « le logiciel est-il conforme ? » La question est : « qui a juridiquement la qualité pour signer l’attestation qui sera présentée au fisc ? »

L’actualité BOFiP du 25 mars 2026 rend ce point très pratique. Elle confirme le retour de l’attestation individuelle, mais rappelle aussi que l’éditeur est celui qui détient le code source et maîtrise la modification des paramètres du logiciel ou du système de caisse. Si personne ne peut assumer clairement ce rôle, l’entreprise contrôlée risque de se retrouver avec un document commercial inutilisable.

Cet article complète notre analyse générale sur le logiciel de caisse 2026, l’auto-attestation et l’amende de 7 500 euros.

Pourquoi les logiciels open source et internes posent un problème particulier

Un logiciel de caisse standard est généralement simple à documenter. L’éditeur vend ou met à disposition une version déterminée. Il fournit un certificat ou une attestation. L’entreprise conserve le document et le présente en cas de contrôle.

La situation change lorsque le logiciel est libre, modifié, branché à plusieurs modules ou développé pour les besoins propres de l’entreprise. Un restaurant peut utiliser une base open source puis y ajouter des remises, des avoirs et une interface de paiement. Un réseau de magasins peut avoir un outil commun, adapté par un prestataire local. Une marketplace peut enregistrer des paiements de particuliers dans un module relié à son ERP. Un commerçant peut utiliser un logiciel en ligne, puis modifier des exports ou des fonctions d’annulation.

Dans ces hypothèses, le risque n’est pas abstrait. L’administration ne vérifiera pas seulement le nom du logiciel. Elle peut demander si la version utilisée respecte les conditions d’inaltérabilité, de sécurisation, de conservation et d’archivage des données. Si la version installée n’est plus celle couverte par l’attestation, le document perd une partie de son intérêt.

Ce que dit le BOFiP depuis le 25 mars 2026

Le BOFiP relatif aux logiciels ou systèmes de caisse sécurisés précise que l’article 125 de la loi de finances pour 2026 a rétabli, depuis le 21 février 2026, la possibilité de justifier la conformité par une attestation individuelle délivrée par l’éditeur.

Le texte est favorable aux entreprises, mais il ne supprime pas les conditions de fond. Le logiciel doit toujours garantir l’inaltérabilité, la sécurisation, la conservation et l’archivage des données d’encaissement. L’attestation est un mode de preuve. Elle n’efface pas une modification technique qui rendrait le système fragile.

Le point décisif est la notion d’éditeur. Le BOFiP explique que l’éditeur est la personne qui détient le code source et qui maîtrise la modification des paramètres du produit. Il ajoute une limite importante : l’éditeur qui fournit l’attestation ne peut pas être l’assujetti à la TVA au nom duquel l’attestation est établie, sauf si cet assujetti exerce une véritable activité d’édition de logiciels ou de systèmes de caisse.

Autrement dit, une boutique, un restaurant ou une société commerciale ne doit pas se fabriquer une attestation pour elle-même simplement parce qu’elle a accès au code ou parce qu’un salarié a développé l’outil. Il faut identifier si l’entreprise est réellement éditrice du logiciel, ou si elle est seulement utilisatrice d’un système adapté.

Logiciel open source : l’attestation générique suffit-elle ?

Le logiciel open source n’est pas interdit. Le BOFiP ne dit pas qu’un logiciel libre serait par nature non conforme. Il indique en revanche que les modifications que les utilisateurs peuvent apporter ne doivent pas avoir pour objet ou pour effet d’altérer les conditions légales.

Le point pratique est donc le suivant : quelle version est utilisée ?

Si l’entreprise utilise une version distribuée par un éditeur identifié, sans modification sensible des fonctions de caisse, elle doit demander à cet éditeur une attestation qui vise la version en cause. Si l’entreprise a modifié le code, ajouté des connecteurs ou changé les paramètres d’annulation, de ticket, de remise, d’avoir ou d’archivage, l’attestation d’origine peut ne plus couvrir la version réellement utilisée.

Il faut alors vérifier :

• qui détient la maîtrise du code modifié ;
• qui peut documenter les changements ;
• qui garantit que les données d’encaissement restent inaltérables et conservées ;
• quelle version est utilisée dans chaque établissement ;
• si un certificat externe devient plus prudent.

La difficulté est forte lorsque la communauté open source n’a pas d’entité juridique capable d’émettre une attestation individuelle. Dans ce cas, l’entreprise doit éviter de s’abriter derrière le caractère libre du logiciel. Le libre accès au code ne remplace pas la preuve administrative attendue.

Logiciel développé en interne : l’entreprise peut-elle signer elle-même ?

Le développement interne est le cas le plus risqué.

Une entreprise peut avoir créé son propre système de caisse parce que son activité est particulière. Un groupe de restauration peut avoir construit un outil unique. Une start-up retail peut avoir développé un module d’encaissement intégré à son application. Un e-commerçant peut avoir relié ventes, avoirs, retours et paiements dans un système propriétaire.

Si l’entreprise utilisatrice est aussi une véritable entreprise d’édition de logiciels de caisse, la situation peut être défendable. Mais si elle exerce seulement une activité commerciale et utilise un outil créé pour elle-même, la signature d’une attestation par son propre dirigeant sera fragile.

La question à se poser est simple : l’entreprise peut-elle démontrer qu’elle est éditeur du logiciel, au sens technique et économique du terme, et pas seulement utilisatrice de son outil interne ?

Si la réponse est incertaine, il faut envisager une certification par un organisme accrédité, une reprise de l’outil par un éditeur identifié, ou une migration vers une solution attestée. Attendre le contrôle fiscal pour trancher ce point est une mauvaise stratégie.

Intégrateur, prestataire informatique, franchise : qui porte le risque ?

Un intégrateur peut installer, paramétrer ou adapter un logiciel. Cela ne signifie pas toujours qu’il est l’éditeur. S’il ne maîtrise pas le code source et ne contrôle pas les paramètres essentiels du produit, son attestation peut être insuffisante.

Le contrat informatique doit donc être relu. Il faut distinguer :

• l’éditeur du logiciel de base ;
• l’intégrateur qui installe ou adapte ;
• le prestataire qui héberge ;
• l’entreprise qui utilise ;
• la tête de réseau qui impose une solution à ses franchisés.

Dans un réseau de franchise, la situation peut devenir sensible. Le franchiseur impose parfois une caisse ou un module d’encaissement, mais le franchisé reste celui qui encaisse et supporte le contrôle. Il doit donc obtenir une documentation claire : certificat ou attestation, version utilisée, périmètre couvert, modules inclus, historique des mises à jour.

Si la solution a été modifiée localement, il faut savoir si la tête de réseau couvre cette modification. À défaut, le franchisé peut se retrouver responsable d’un système qu’il n’a pas choisi et qu’il ne maîtrise pas techniquement.

Contrôle fiscal : les pièces à préparer avant la demande de l’administration

En cas de contrôle, l’administration peut demander la preuve de conformité du logiciel ou système de caisse. L’entreprise doit produire un document exploitable rapidement. Une promesse de l’éditeur ou un courriel commercial ne suffit pas.

Le dossier doit contenir :

• la liste des logiciels et systèmes de caisse utilisés ;
• la version exacte installée ;
• l’identité de l’éditeur ;
• le certificat ou l’attestation individuelle ;
• le périmètre couvert par le document ;
• les modules ajoutés ou développés en interne ;
• les dates de mise à jour importantes ;
• les établissements ou terminaux concernés ;
• les procédures d’annulation, d’avoir, de remise et d’archivage ;
• les contrats avec l’éditeur, l’intégrateur ou le franchiseur.

Ce dossier permet de répondre vite. Il permet aussi d’identifier une faille avant le contrôle. Si l’attestation ne vise pas la bonne version ou si un module d’encaissement a été ajouté sans validation, il faut corriger avant que l’administration ne le découvre.

Amende de 7 500 euros : le risque n’est pas seulement théorique

Le risque fiscal est connu : l’absence de certificat ou d’attestation conforme peut exposer l’entreprise à l’amende prévue pour les logiciels ou systèmes de caisse non justifiés. Le montant de 7 500 euros peut s’appliquer par logiciel ou système concerné, avec obligation de régularisation dans le délai imparti.

Le vrai coût peut être plus élevé. Une entreprise qui change de caisse dans l’urgence supporte une migration, une formation, une interruption d’exploitation et parfois une remise en cause de ses données historiques. Un réseau multi-sites peut devoir reconstituer plusieurs années de versions et de tickets. Un e-commerçant peut découvrir que son module de paiement, son ERP et son système d’avoir ne racontent pas la même histoire.

Le contrôle du logiciel de caisse peut aussi ouvrir d’autres sujets : TVA collectée, annulations, remises, avoirs, ventes en espèces, rapprochement bancaire, exports comptables et cohérence du chiffre d’affaires déclaré.

Que faire si vous utilisez un logiciel modifié

La première décision consiste à cartographier les outils. Beaucoup d’entreprises parlent de « la caisse » alors qu’elles utilisent plusieurs systèmes : terminal physique, module de paiement, back-office e-commerce, ERP, logiciel de facturation, outil de fidélité, application de réservation.

La deuxième décision consiste à demander une attestation précise. Elle doit viser le bon logiciel, la bonne version et les fonctionnalités de caisse. Si l’éditeur refuse ou répond de manière vague, il faut documenter ce refus et chercher une solution.

La troisième décision consiste à qualifier les modifications. Une interface de reporting n’a pas le même risque qu’une modification permettant de supprimer une vente, d’éditer un ticket, d’annuler un règlement ou de modifier l’historique.

La quatrième décision consiste à arbitrer entre trois options : obtenir une attestation valable, faire certifier le système, ou migrer vers une solution documentée. Le choix dépend du nombre de points de vente, du coût de migration, du risque de contrôle, du volume de paiements de particuliers et de la capacité technique de l’entreprise.

Paris et Île-de-France : enjeu fort pour commerces, restaurants et réseaux

À Paris et en Île-de-France, le sujet concerne directement les commerces, restaurants, franchises, boutiques de services, établissements recevant du public, salles de sport, instituts, concept stores, plateformes locales et entreprises multi-sites.

La densité commerciale augmente le risque de solutions bricolées : caisse historique, logiciel métier ancien, module de paiement récent, outil de fidélité, exports comptables, puis adaptation locale par un prestataire. Ce montage peut fonctionner au quotidien, mais être difficile à expliquer lors d’un contrôle fiscal.

Pour une entreprise francilienne, la bonne méthode consiste à préparer un dossier court avant toute demande de l’administration : outils utilisés, éditeurs, versions, attestations, contrats, modifications et responsable technique. Ce dossier peut ensuite être transmis à l’expert-comptable, à l’avocat et au prestataire informatique pour arbitrer les corrections.

Sources utilisées

• BOFiP, Obligation d’utilisation de logiciels ou systèmes de caisse sécurisés, version publiée le 25 mars 2026.
• Entreprendre.Service-Public, Rétablissement de l’utilisation des logiciels de caisse auto-certifiés, 24 février 2026.
• Ministère de l’Economie, Ce qu’il faut savoir sur la certification des logiciels de caisse.
• Légifrance, article 286 du Code général des impôts.

Besoin d’un avis rapide sur votre dossier.

Consultation téléphonique en 48 heures avec un avocat du cabinet.

Le cabinet peut relire votre attestation éditeur, vos contrats avec l’intégrateur, votre documentation de caisse ou votre dossier de réponse à un contrôle fiscal.

Appelez le 06 46 60 58 22 ou utilisez le formulaire de contact.

Pour une entreprise à Paris ou en Île-de-France, l’analyse peut intégrer vos points de vente, votre e-commerce, vos prestataires informatiques, votre expert-comptable et les pièces à préparer avant contrôle.

Voir aussi notre page dédiée aux avocats en droit des affaires à Paris.