Source: https://greboca.com/@DLFP-Depeches@.html?ids=34881&lang=fr
Timestamp: 2019-06-25 16:53:55+00:00
Document Index: 62047930

Matched Legal Cases: ['§\u202f1', '§\u202f30', '§\u202f30', '§40', '§\u202f270', '§\u202f300', '§\u202f80', '§\u202f130', '§\u202f40', '§300', '§\u202f315', '§\u202f380', '§\u202f40', '§\u202f360', '§\u202f300', '§\u202f375', '§\u202f290', '§\u202f230', '§\u202f310']

DLFP - Dépêches - Les logiciels libres de caisse de mieux en mieux pris en compte par Bercy
lien n°1 : Article 286 3ᵒ bis du code général des impôts
lien n°2 : Mise à jour du BOI-TVA-DECLA-30-10-30 de juillet 2018 (la doctrine fiscale)
lien n°3 : Analyse de l’April sur la première version du BOI-TVA-DECLA-30-10-30
Qui est concerné ? Quels logiciels ?
Quelles sont les obligations ?
Est‐il possible d’utiliser des logiciels libres ?
À propos de l’attestation individuelle :
Qui peut attester ?
Est‐il possible d’attester pour soi‐même ?
Que se passe‐t‐il en cas de mise à jour « majeure » invalidant l’attestation émise ?
Quelle suite ?
Le 1er janvier 2019 marquera la fin d’une année dite de « tolérance » des services fiscaux. Bien qu’il demeure des pistes d’amélioration importantes, l’April est rassurée par rapport à la première version du texte. Particulièrement suite à la mise à jour du BOFIP (Bulletin officiel des finances publiques — Impôts) en juillet 2018 à laquelle l’association a participé, d’abord en rencontrant les personnes en charge du dossier au sein du ministère, puis en répondant à un appel à commentaires sur la version « projet » du document. Dans les grandes lignes, il ressort de cette mise à jour une bien meilleure sécurité juridique ; meilleure définition et champ d’application plus précis notamment. Pas de grand changement en ce qui concerne le logiciel libre. Des rigidités demeurent, comme pour l’auto‐attestation, mais la dynamique est positive et encourageante.
La loi de finances pour 2016 a créé une nouvelle réglementation des logiciels de caisse dans l’objectif de lutter contre la fraude à la TVA. Dispositif inscrit au 3ᵒ bis du I de l’article 286 du code général des impôts (CGI) et entré en vigueur au 1er janvier 2018. Appliquée telle quelle, la nouvelle réglementation aurait interdit de fait l’utilisation de logiciels libres de caisse en rendant théoriquement illicite toute modification par les utilisateurs.
En août 2016, une première publication au BOFIP, le BOI-TVA-DECLA-30-10-30 (ancienne version), est venue préciser le périmètre de la réglementation. Ce document est doublement important : d’une part, il a force de loi, il est opposable à l’administration, et, d’autre part, il reconnaît explicitement la possibilité d’utiliser des logiciels libres de caisse. Un document que l’April avait commenté, soulignant les avancées du texte ainsi que les améliorations attendues.
En juin 2017, le gouvernement répond dans un communiqué de presse à l’expression d’une inquiétude grandissante quant au périmètre exact du dispositif. Le document confirme l’exclusion des logiciels de comptabilité et annonce une année de tolérance administrative jusqu’au 1er janvier 2019. L’annonce est traduite en norme dans la loi de finances pour 2018 (article 105).
Les services de Bercy en charge du dossier font un appel à commentaires sur leur projet de mise à jour du BOFIP fin 2017, auquel l’April contribue. Le 4 juillet 2018 la nouvelle version du BOFIP est mise en ligne. Plus précisément, il s’agit d’une mise à jour du BOI-TVA-DECLA-30-10-30, colonne vertébrale du dispositif, et du BOI-CF-COM-20-60-20 qui précise les modalités du contrôle des logiciels de caisse par les services fiscaux.
Indéniablement, la mise à jour du BOFIP confirme une dynamique de sécurisation juridique précisant davantage le champ d’application, clarifiant et améliorant les définitions, recadrant ce qui relève des responsabilités de chacun. Plus spécifiquement, en ce qui concerne les logiciels libres, on sent une réelle volonté d’avoir un texte proportionné qui ne restreigne les libertés informatiques qu’à hauteur, selon ses rédacteurs, de ce qui est nécessaire à l’objet du texte, c’est‐à‐dire la lutte contre la fraude à la TVA. Pour autant, le paradigme de l’informatique privatrice pensée en silo reste présent et impose ses contraintes. Il reste une marge de progression encore importante pour les logiciels libres. Le cas de l’auto‐attestation en est l’exemple éloquent.
Le site des services fiscaux propose un outil très simple destiné à savoir si l’on est ou non concerné par le dispositif.
Toute personne assujettie à la taxe sur la valeur ajoutée (TVA) qui enregistre les règlements de ses clients au moyen d’un logiciel ou d’un système de caisse. C’est la fonctionnalité d’encaissement qui importe, plus précisément « l’enregistrement extra‐comptable des paiements reçus ». Ne sont donc pas concernés les logiciels ou systèmes qui déclenchent « obligatoirement, instantanément et automatiquement, sans intervention humaine, une écriture dans le système d’information comptable ». Le moyen de paiement ou le fait que le système soit hébergé localement ou en ligne n’a d’ailleurs aucune incidence sur l’application ou non du dispositif.
Paragraphes de référence : Qui ? ; § 1 et 10, Quels logiciels ? ; § 30, 35 et 40 BOI-TVA-DECLA-30-10-30 (BOI-TVA ci‐après).
§ 30 BOI-TVA :
« Un logiciel ou système de caisse est un système informatique doté d’une fonctionnalité de caisse, laquelle consiste à mémoriser et à enregistrer extra‐comptablement des paiements reçus en contrepartie d’une vente de marchandises ou de prestations de services c’est‐à‐dire que le paiement enregistré ne génère pas concomitamment, automatiquement et obligatoirement la passation d’une écriture comptable. […] Seule cette fonctionnalité de caisse, et non les autres fonctions telles que celles relatives à la pesée, doivent être certifiées [ou attestées, N. D. R]. […] »
§40 BOI-TVA :
« Un logiciel, quelle que soit sa qualification (de caisse, comptable ou de gestion), qui dispose d’une fonctionnalité de caisse doit satisfaire aux conditions d’inaltérabilité, de sécurisation, de conservation et d’archivage des données en vue du contrôle de l’administration fiscale. »
Pour les personnes utilisatrices : en cas de contrôle, elles devront fournir (ou « produire ») une certification ou une attestation individuelle remise par l’éditeur établissant que les fonctions d’encaissement du logiciel ou système satisfont les « conditions d’inaltérabilité, de sécurisation, de conservation et d’archivage des données en vue du contrôle de l’administration fiscale » (les « quatre conditions »). Elles doivent donc avoir un document à jour correspondant à la version du logiciel ou système qu’elles utilisent. Paragraphes de référence : § 270 à 290 BOI-TVA
Pour les intégrateurs (compris dans la qualification d’éditeurs du dispositif)1 : faire certifier leur logiciel ou système de caisse, ou attester que celui‐ci satisfait les quatre conditions. La mise à jour du BOFIP vient préciser ce qui est attendu en termes de respect de celles‐ci, donc le niveau de responsabilité attaché aux éditeurs, confirmant ainsi qu’il ne s’agit pas d’exiger une inaltérabilité absolue, par exemple, mais davantage d’empêcher la dissimulation des données originales. Paragraphes de référence sur la notion d’éditeur : § 300, 310 et 315 BOI-TVA.
La mise à jour du BOFIP marque une importante avancée sur la question des obligations, en distinguant plus clairement ce qui est attendu des intégrateurs et des utilisateurs et en abaissant l’intensité des obligations. Il semblerait en ce sens que l’on soit passé d’une apparente obligation stricte de résultat vers ce qui s’assimilerait davantage à une obligation de moyens renforcée. Paragraphes de référence : sur l’inaltérabilité § 80 à 120, sur la sécurisation § 130 à 150 BOI-TVA.
Oui. Le texte définit le logiciel libre en rappelant les quatre libertés et intègre dans la dynamique du dispositif la liberté pour l’utilisateur de modifier son logiciel, dans le respect des quatre conditions. C’était la principale avancée de la première version du BOFIP, traduite dans la manière dont est définie la notion d’éditeur. Ainsi, le « dernier intervenant ayant paramétré le logiciel ou système lorsque son intervention a eu pour objet ou effet de modifier un ou des paramètres permettant le respect des conditions d’inaltérabilité, de sécurisation, de conservation et d’archivage des données », sera éditeur. Dit autrement, l’utilisateur est libre de modifier son logiciel. Et s’il fait une modification qui concerne une ou plusieurs des quatre conditions, une modification « majeure », c’est lui qui sera considéré comme l’éditeur du logiciel et il sera donc responsable des obligations qui s’y attachent. Une précision indispensable pour éviter qu’un éditeur de logiciel libre soit indéfiniment responsable des éventuels comportements délictueux de son client.
Paragraphes de référence : § 40, pour la définition de logiciel libre, §300, 310 et § 315, sur l’aménagement de la notion d’éditeur.
Parallèlement, la liberté pour l’utilisateur d’effectuer des modifications « mineures » est explicitée. Ces modifications ne concernant pas les fonctionnalités d’encaissement sont possibles sans entacher la validité de l’attestation ou de la certification. Le BOFIP précise que l’attestation doit clairement identifier « la racine de la dernière version majeure ». (§ 380 BOI-TVA)
§ 40 BOI-TVA :
« Un logiciel libre est un logiciel dont les utilisateurs ont un libre usage, une libre étude, une libre modification et une libre distribution. Un logiciel propriétaire, au contraire, ne permet ni légalement ni techniquement d’exercer ces quatre libertés, qui permettent aux utilisateurs d’adapter le logiciel à leurs besoins spécifiques. »
Une attestation est « individuelle ». Elle se fait donc au cas par cas, pour chaque client, sur la base du modèle BOI-LETTRE-000242. À l’inverse, un certificat délivré par une autorité agréée a une portée générale. Ces documents concernent une version « majeure » d’un logiciel ou système, ou plus précisément de ses fonctionnalités d’encaissement.
Paragraphes de référence : § 360 à 390 du BOI-TVA.
N’importe qui peut attester « pour autrui ». Cela signifie que l’éditeur qui atteste verra sa responsabilité engagée si le logiciel est contrôlé et ne satisfait pas les « quatre conditions ». Cependant, si l’utilisateur a effectué une modification « majeure », il est alors considéré comme éditeur de la version utilisée, rompant donc le lien de responsabilité. L’ajout d’une mention au § 300 BOI-TVA explicite clairement ce point ; « une attestation délivrée par un éditeur engage sa responsabilité sous réserve que les dispositifs techniques garantissant sécurisation, inaltérabilité, conservation et archivage ne sont pas modifiés par un tiers. »
Oui. Suite à sa mise à jour, le BOFIP assouplit un peu cette possibilité en ne la conditionnant plus exclusivement à la détention d’un code NACE (Nomenclature des Activités économiques dans la Communauté Européenne). Il ne s’agit plus que d’un moyen de preuve pour démontrer une « activité réelle et corroborée » d’édition de logiciel. C’est un progrès certain, mais il nous semble possible d’aller beaucoup plus loin sans affaiblir le dispositif. Nous estimons notamment qu’une activité matériellement démontrable d’édition du logiciel (contributions à une forge logicielle basée sur Git, par exemple) pourrait être un élément de preuve proportionné.
Paragraphe de référence : § 375 BOI-TVA.
Précision importante apportée par cette mise à jour du BOFIP et issue d’une des propositions de l’April : c’est à l’utilisateur qu’incombe d’avoir un logiciel et une attestation à jour. Si ce genre de situation sera aisément précisé — dans des contrats de prestation, par exemple — il s’agit d’une clarification importante qui évite à un éditeur qui maintient à jour son logiciel pour qu’il satisfasse les quatre conditions, d’être responsable si un utilisateur ne maintient pas son système à jour ou s’il ne renouvelle pas son attestation, potentiellement devenue caduque s’il mettait à jour son logiciel vers une nouvelle version majeure.
Paragraphe de référence : § 290 BOI-TVA.
Précisons également que la mise à jour du BOFIP a été l’occasion de combler un manque important : l’obligation de recourir à des formats ouverts pour enregistrer des données d’archivage (§ 230 BOI-TVA). La question des formats ouverts est fondamentale et intrinsèque à toute réflexion sur le logiciel libre. Sans cette garantie d’interopérabilité il ne peut y avoir de libertés informatiques pleines et entières. Cette obligation sans équivoque apportée au BOFIP est donc un apport judicieux au dispositif.
À un mois de la fin de la période de « tolérance administrative », l’April se montre confiante dans l’application de la réglementation pour les acteurs et utilisateurs de logiciels libres de caisse, particulièrement eu égard à l’attitude constructive de l’administration fiscale sur ce dossier.
Ne nous y trompons pas. L’objet de cette loi était d’adresser les mauvaises pratiques, parfois frauduleuses, de certains éditeurs de logiciels privateurs. Ainsi, malgré les craintes initiales liées à la rédaction du texte, l’April et les représentants de logiciels libres français concernés par cette loi ont accueilli positivement cette réglementation qui permet d’assainir le marché des logiciels de caisse et d’apporter davantage de sécurité juridique.
Dans ses premières versions, le dispositif était révélateur d’une représentation purement privative de l’informatique, sous forme de boîte noire, et était disproportionné dans ses atteintes aux libertés informatiques. Bien que l’on ne soit pas encore totalement sorti de ce paradigme, l’April salue l’attitude constructive des services de Bercy en charge du dossier et note une dynamique positive dans les évolutions successives du BOFIP. Jusqu’à aboutir aujourd’hui à une version bien plus équilibrée qui intègre de manière globalement satisfaisante le logiciel libre et ses modèles de développement. L’association restera évidemment mobilisée sur ce sujet et espère maintenir cette qualité d’échanges avec l’administration, dans un esprit de transparence et de coopération, valeurs fondamentales du mouvement du logiciel libre.
Le dispositif utilise le terme d’« éditeur » pour qualifier la catégorie de personnes concernées par les obligations de certification et d’attestation. Mais la notion d’éditeur doit être entendue dans un sens large, englobant par exemple le prestataire qui fera de l’intégration et/ou qui s’occupera de maintenir le système à jour dès lors qu’il sera « le dernier intervenant ayant paramétré le logiciel ou système lorsque son intervention a eu pour objet ou effet de modifier un ou des paramètres permettant le respect des conditions d’inaltérabilité, de sécurisation, de conservation et d’archivage des données » (§ 310 BOI-TVA). Nous parlerons ainsi régulièrement d’intégrateur en substitution du terme éditeur, plus caractéristique de l’informatique privatrice. Il nous semble en effet que dans le domaine de l’encaissement, les logiciels libres sont essentiellement communautaires. La vente de prestation est le fait d’intégrateurs qui peuvent être minoritaires parmi les contributeurs directs au code source du logiciel. ↩
par Etienne Gonnu, ZeroHeure, Davy Defaud, palm123