Mise à jour du 16 juin 2017 : précision sur le champ d'application [5] suite à une déclaration du cabinet du ministre de l'Action et des Comptes publics.
Comme indiqué dans notre dernier point d'étape [6] sur ce dossier l'article 88 de la loi de finances de 2016 [7] marque la volonté du gouvernement français de lutter contre la fraude fiscale par un encadrement plus strict des logiciels de comptabilité, de gestion ou d’encaissement. Le texte aurait pu avoir pour effet de bord l'interdiction de détenir des logiciels libres de caisse. L'administration, que nous avons rencontrée, a visiblement été sensible à ce problème et a fait preuve d'une attitude conciliante et constructive. Notre principale crainte a été ainsi levée, même s'il reste des points d'amélioration. Les dispositions, codifiées à l'article 286, I. 3° bis du code des impôts, entreront en vigueur le 1er janvier 2018.
Pour des recommandations plus concrètes de mise en conformité avec la loi de finances vous pouvez notamment vous reporter à ce billet de l'éditeur Pastèque [8].
Doctrine de l'administration fiscale
En août 2016, l'administration fiscale a publié au BOFIP (Bulletin officiel des finances publiques — Impôts), son interprétation de l'article 88 de la loi de finances. Le BOI-TVA-DECLA-30-10-30 [9] (« BOI » ci-après), correspond donc à la doctrine de l'administration, la manière dont elle entend appliquer la loi. Un document très important puisqu'il lui est opposable [10]. Pour rappel, la publication du BOI s'inscrit dans la suite d'échanges avec l'administration fiscale qui avait communiqué son projet de commentaires au BOFIP [11] et c'est notamment par les précisions apportées par ce texte que le risque d'une interdiction de fait des logiciels libres de caisse a été écarté.
Ci-dessous un résumé des principales questions et problématiques. Suivi d'une analyse critique plus détaillée dont il ressort que le texte reste mal adapté à la réalité du modèle de développement des logiciels libres dont les qualités intrinsèques sont pourtant des atouts pour la lutte contre la fraude fiscale. Il faut cependant garder à l'esprit que chaque loi de finances, et chaque nouvelle révision du BOFIP, sera une occasion d'inciter à une meilleure prise en compte des logiciels libres.
Résumé des principales questions et problématiques
Qui est concerné ?
À compter du 1er janvier 2018, toute personne assujettie à la taxe sur la valeur ajoutée (TVA) qui enregistre les règlements de ses clients au moyen d'un logiciel de comptabilité ou de gestion ou d'un système de caisse. S'il y a peu de doute sur le fait que ce soient les fonctionnalités d'encaissement qui sont visées, cela mériterait d'être explicité.
En cas de contrôle, il faudra fournir (ou « produire ») une certification ou une attestation délivrée par l'éditeur établissant que le logiciel satisfait 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 »).
Est-il possible d'utiliser des logiciels libres ?
Oui. Le paragraphe 40 du BOI le dit explicitement en reconnaissant aux utilisateurs la possibilité « d'adapter le logiciel à leurs besoins spécifiques ». Par ailleurs, le paragraphe 310 prend en compte le cas des logiciels « conçus de manière ouverte », c.à.d les logiciels libres.
L'utilisateur bénéficie de sa pleine liberté de modification en ce qui concerne les paramètres « triviaux » du logiciel. Si les modifications impactent les « quatre conditions » l'utilisateur, devenu éditeur, devra faire certifier, faire attester ou attester pour lui-même (s'il le peut, voire infra) que la nouvelle version du logiciel satisfait ces exigences.
Pour que l'attestation demeure valable en cas de modification triviale l'éditeur doit (§380) ; « identifier clairement la racine de la dernière version majeure à la date d'émission de l'attestation et les subdivisions de cette racine qui sont ou seront utilisées pour l'identification des versions mineures ultérieures ».
Ces précisions apportées par le BOI sont importantes mais perfectibles.
À propos de l'attestation :
Une attestation est « individuelle » (§370). Elle se fait donc au cas par cas, pour chaque client, sur la base du modèle BOI-LETTRE-000242 [12]. Un certificat, délivré par une autorité agréée, a une portée générale et concerne une version (majeure) d'un logiciel.
- Qui peut attester ?
N'importe qui peut attester « pour autrui ». Cela signifie que l'éditeur qui atteste engage sa responsabilité si le logiciel est contrôlé et ne satisfait pas les « quatre conditions ». Sauf si l'utilisateur a modifié un paramètre impactant les « quatre conditions » alors que ce paramètre était clairement identifié.
- Est-il possible d'attester pour soi-même ?
Oui. Mais le BOI conditionne cela à la détention du code NACE (nomenclature des activités économiques dans la Communauté européenne) d'une « activité d'édition de logiciels de comptabilité ou de gestion ou de systèmes de caisse ». Le code le plus approchant est le 58.29 sur l' « édition d'autres logiciels » [13]. L'administration devra préciser ce point. Sans le code approprié il faudra faire attester la nouvelle version du logiciel par un autre éditeur (qui n'aura pas besoin de ce code puisqu'il attestera pour autrui). Non bloquant dans la pratique, mais inutilement rigide.
Précisions pour les développeurs et utilisateurs de logiciels libres de caisse
Le BOFIP apporte des précisions aux développeurs et utilisateurs de logiciels libres de caisse nécessaires pour garantir leurs libertés informatiques. Toutefois, il reste encore trop d'incertitudes et d'imprécisions pour que ce texte soit pleinement satisfaisant.
Des définitions plus claires pour une meilleure prise en compte des logiciels libres
- Une avancée symbolique : une définition plus juste des logiciels libres.
Le projet de commentaires de l'administration qualifiait les logiciels libres comme des logiciels « dont la principale caractéristique est d'être librement paramétrables ». Désormais le BOI, au paragraphe 40, mentionne explicitement les quatre libertés et préfère le terme « adapter » à « paramétrer ». Ce changement n'est pas anodin ; il confirme la reconnaissance institutionnelle croissante de ce qu'est un logiciel libre [14] et des libertés qu'il garantit.
- Une définition de l'« éditeur » qui concilie mieux le lien de responsabilité et liberté de modification.
Pour lutter contre la fraude fiscale, la nouvelle réglementation impose que les logiciels utilisés soient certifiés conformes par une autorité certifiante, ou soient assortis d'une attestation individuelle fournie par l'éditeur du logiciel qui peut donc voir sa responsabilité engagée en cas de fraude par l'utilisateur. Sans clarification, ce lien de responsabilité pouvait avoir des conséquences lourdes pour le modèle du logiciel libre, notamment en ce qui concerne la liberté de modification. Ce point était la source de la principale inquiétude de l'April et de certains éditeurs ; une responsabilité « infinie » imposant de fait aux éditeurs d'entraver la liberté de modification des utilisateurs. La définition inscrite aux paragraphes 300 et 310 du BOI circonscrit ce risque.
Le paragraphe 300 du BOI définit ainsi comme « éditeur du logiciel ou du système de caisse la personne qui détient le code source [15] du logiciel ou système et qui a la maîtrise de la modification des paramètres de ce produit. ». Le paragraphe 310 vient ensuite préciser que « lorsque le logiciel ou système est conçu de manière ouverte pour permettre son adaptation aux besoins spécifiques des clients » , l'éditeur est soit le concepteur d'origine si les modifications concernant les quatre conditions essentielles sont impossibles soit le dernier intervenant si « 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 ».
Cette seconde option est importante puisqu'elle permet, sans restreindre la liberté de modification, à tout prestataire de fournir une attestation en tant qu'éditeur, tout en rompant le lien de responsabilité en cas de modification d'éléments non-triviaux du logiciel par l'utilisateur. L'utilisateur devient en ce cas lui-même l'éditeur, et doit alors faire certifier ou attester la conformité du logiciel ainsi modifié.
Pour résumer : large applicabilité du dispositif d'attestation de l'éditeur pour autrui et possibilité de modifier des éléments triviaux sans remise en cause de l'attestation (mếme s'il reste des points de vigilance, voir plus bas).
Petit bémol : le premier tiret du paragraphe 310 qui ne couvre pas le cas des logiciels libres puisqu'il interdit la possibilité de modification non-triviale par toute personne autre que le concepteur. Cela sous-entend-il la création de « boîtes noires » au sein des logiciels comme cela fut le cas — et un échec criant — en Belgique ? [16] Cela s'oppose directement à la notion d'un système ouvert de la première partie de la définition et induit une incertitude inutile quant aux obligations que l'administration entend faire peser sur les éditeurs de logiciels libres. Un bémol aux conséquences certainement plus théoriques que pratiques.
Des aspects qui gagneront à être précisés
- Un champ d'application défini de manière trop large par rapport à l'objet de la loi ?
Lors des débats parlementaires, l'article 88 avait été justifié par la lutte contre « la dissimulation de recettes de taxe sur la valeur ajoutée (TVA) au moyen de logiciels de caisse frauduleux » [17]. Autrement dit la soustraction de paiements en espèce au point de vente. La formulation du texte de loi est malheureusement ambiguë en ce qu'elle peut laisser craindre un champ d'application plus large, incluant les logiciels de comptabilité pure. Le paragraphe 10 du BOI reprend cette expression ambiguë sans la commenter.
En cohérence avec l'intention du législateur, les organismes de certification considèrent que le champ d'application est limité aux logiciels incluant des fonctionnalités d'encaissement, à l'exclusion des logiciels de comptabilité pure. Voir en ce sens le référentiel du Laboratoire National de métrologie et d'Essais (LNE) [18]. Cet organisme précise ainsi qu'il « exclut du domaine d’application de la certification les logiciels servant au support des services après-vente (rapports de maintenance, rapports de services, génération de bons d’intervention, etc.) ainsi que les logiciels de comptabilité pure ou les applications monétiques (terminaux de paiement électroniques par exemple) ».
La plupart des projets libres se basent sur cette interprétation.Une définition plus précise de la part de l'administration apporterait davantage de confiance en réduisant une potentielle insécurité juridique.
Mise à jour du 16 juin 2017 :
Suite à la mobilisation de la Fédération française des auto-entrepreneurs [19] le cabinet du ministre de l'Action et des Comptes publics a annoncé le 15 juin 2017 [20] que le dispositif de la loi de finances pour 2016 serait recentré et simplifié. « Seuls les logiciels et systèmes de caisse, principaux vecteurs des fraudes constatées à la TVA, seront ainsi concernés ».
Le ministère assure ainsi que « cette modification fera l’objet de mesures législatives d’ici la fin d’année [2017] ». Précision utile et bienvenue. Cet amendement de la loi sera également l'occasion de clarifier d'autres sources d'insécurité juridique, en particulier : la notion de modification « majeure » du logiciel et la nature de l'impératif « d'inaltérabilité » des données. Enfin, la forte mobilisation de cette fédération sur un point qui semble surtout relever du flou dans la sémantique juridique montre que l'administration fiscale devra faire un important travail de pédagogie dans la mise en oeuvre du dispositif.
- Paramètres triviaux et non-triviaux ; une distinction importante mais par aspect trop théorique.
Le deuxième point du §310 laisse entendre qu'une nouvelle attestation du professionnel intervenant sur le logiciel est seulement nécessaire 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. À contrario, l'attestation d'origine resterait donc valable dans le cas d'une modification « triviale ».
Cette prise en compte de l'existence de fonctionnalités « triviales » révèle in fine une meilleure reconnaissance de la liberté de modification, et semble mieux préciser le partage des responsabilités que l'administration envisage entre l'éditeur et l'utilisateur.
En somme, un utilisateur pourra modifier les éléments triviaux du logiciel sans entacher l'attestation ou certification qui lui a été remise par l'éditeur.
À l'inverse, on pourrait ainsi considérer que si ce qui relève des quatre conditions essentielles d'inaltérabilité, de sécurisation, de conservation et d'archivage des données a été clairement identifié, alors la responsabilité de l'éditeur initial, ou du dernier à avoir valablement attesté, ne sera pas engagée en cas de modification majeure, voire d'utilisation frauduleuse du logiciel.
Toutefois, cette prise en compte des modifications « triviales » gagnerait à être plus explicite. Les paragraphes 340 et 380 abordent la question des « versions majeures » et « mineures » du logiciel, mais en gardant comme seul critère distinctif l'impact sur les quatre conditions essentielles.
En outre, dans la pratique, une telle distinction n'est pas aussi aisée que l'administration semble l'entendre. En effet, même un fonctionnalité d'apparence triviale, pourrait avoir des impacts sur le fonctionnement général du logiciel. Potentielle source d'insécurité juridique qui gagnera à être adressée par des critères plus fins et plus adaptés à la réalité du développement logiciel.
- L'inaltérabilité des données : une obligation à la portée encore trop incertaine.
Dès la publication de l'article 88 de la loi de finances 2016, la question de l'obligation d'inaltérabilité des données est apparue comme un des points de vigilance principaux pour le logiciel libre.
Assez peu d'évolutions concernant cet aspect depuis le projet de commentaires, si ce n'est une structuration du texte peut-être un peu plus claire dans le BOI, mais la traduction en termes techniques du principe comptable d'« intangibilité des écritures » qui a été retenue crée encore trop d'incertitudes pour être pleinement satisfaisante. Ainsi le paragraphe 120 qui établit sans autre précision que « pour respecter la condition d’inaltérabilité, l'intégrité des données enregistrées doit être garantie dans le temps par tout procédé technique fiable », laisse une marge d'interprétation trop importante sur la portée de l'obligation.
Ce point est important en ce qu'il se lie avec la problématique de la responsabilité. Aucune procédure techniquement fiable à 100% n'est possible. Pourtant la simple démonstration d'un usage frauduleux suffit à invalider l'attestation ou à la qualifier de « faux document » (paragraphe 570) : c.à.d attestant à tort de la conformité du logiciel et engageant donc la responsabilité de l'éditeur. La formulation retenue pourrait ainsi laisser entendre que les éditeurs sont soumis à une « obligation de résultat », un logiciel 100% fiable, plutôt qu'une « obligation de moyens » ; un logiciel le plus fiable possible selon l'état de l'art. Même si la seconde hypothèse semble l'interprétation la plus raisonnable de la doctrine fiscale, les conséquences potentielles qui s'y rattachent nécessitent un périmètre mieux défini. Ainsi, sans sombrer dans un alarmisme inutile, il s'agit avant toute chose de renforcer la sécurité juridique des TPE/PME, l'essentiel des acteurs du libre, pour qui la confiance est un élément clef.
Cela étant dit, cette réflexion n'est pas propre aux cas des logiciels libres et ceux-ci ont l'avantage sur les logiciels privateurs de permettre une identification bien plus rapide de potentielles failles de sécurité.
Un système d'auto-attestation défini de manière trop rigide : l'enjeu d'une meilleure reconnaissance des vertus du libre
S'il est possible pour tout éditeur de fournir une attestation de conformité à un utilisateur — cette dernière engage sa responsabilité — la possibilité d'attester pour soi-même en cas de modification de paramètres non-triviaux du logiciel est restreinte.
Elle s'appuie exclusivement sur le code NACE.
Au paragraphe 370, il est ainsi précisé que seule une société dont l'activité déclarée « est une activité d'édition de logiciels de comptabilité ou de gestion ou de systèmes de caisse »
peut « auto-attester » de la conformité du logiciel de caisse avec les obligations issues de l'article 286, I. 3° bis du code général des impôts.
Et dans la mesure où il est illégal d'utiliser un logiciel qui ne serait pas valablement certifiée ou attestée conforme, modifier pour soi-même son outil de gestion sans ce code NACE nécessitera, par exemple, de passer par des accords entre éditeurs d'une même solution libre. Procédure inutilement lourde.
D'autant plus qu'il n'existe aucune classification NACE spécifique aux éditeurs de logiciel « comptabilité ou de gestion ou un système de caisse », celle la plus approchant est la 58.29 [13] sur l' « édition d'autres logiciels ». S'agirait-il d'une imprécision visant à anticiper d'éventuelles évolutions ?
D'autre part, quand bien même le critère du code NACE serait pertinent, il est bien trop rigide comme critère exclusif, en particulier parce qu'il ne concerne que l'activité principale d'une société. Dans un modèle ouvert et contributif comme celui du logiciel libre cela est un frein évident, notamment dans le cas des sociétés ayant plusieurs secteurs d'activité ou dans le cas de contributeurs non professionnels. Particulièrement si l'on considère que l'implication des utilisateurs est au coeur de la dynamique de développement des logiciels libres. Cette limitation de la liberté de modification en cas de développement pour soi-même est d'autant plus disproportionnée que les risques de fraude « généralisée » seront largement contenus par un modèle ancré sur la transparence et la revue par les pairs. Les dérives dues aux boites noires ne doivent pas pénaliser les logiciels libres. Une attestation par la communauté, ou portant sur le modèle de gouvernance d'un projet, pourrait par exemple être une solution plus proportionnée à l'objectif poursuivi.
En conclusion, un texte mieux rédigé mais encore mal adapté à la réalité du modèle de développement des logiciels libres.
Pour résumer nos attentes : des définitions et des critères plus précis pour plus de sécurité juridique et donc de confiance,
et davantage de souplesse dans les conditions d'auto-attestation.
Une obligation d'identifier clairement ce qui relève des quatre critères essentiels, et donc du périmètre de l'attestation,
combiné avec la facilité d'audit garanti par les logiciels libres, devrait être considérées comme suffisantes et proportionnées à l'objectif légitime de lutte contre la fraude fiscale.
Il est bien sûr entendu que ces problématiques sont complexes et que c'est aussi par l'usage et par l'échange qu'une doctrine fiscale plus claire se dégagera. Nous appelons en ce sens à la vigilance de l'administration et souhaitons qu'elle garde l'attitude ouverte qu'elle a eue jusqu'à présent.
Quoiqu'il en soit, la crainte initiale à la lecture de l'article 88 était l'interdiction de fait des logiciels libres « de comptabilité ou de gestion ou un système de caisse ». Ce risque semble heureusement écarté. En revanche, la dynamique du texte initial ainsi que celle du BOI restent ancrées sur le modèle fermé du logiciel privateur [21] comme norme, avec un aménagement en marge pour le modèle ouvert et contributif du logiciel libre. Les qualités intrinsèques du logiciel libre, particulièrement sa caractéristique de transparence, sont des atouts incontestables pour la lutte contre la fraude fiscale. Le recours au logiciel libre devrait en ce sens être privilégié et encouragé. Dans un tout autre domaine, l'exemple du scandale Volkswagen [22] où un logiciel opaque a permis au constructeur de frauder sur les normes environnementales pendant plusieurs années l'illustre bien.