Loi de finances 2016, la fin des logiciels libres de comptabilité et de gestion de caisses ?
Cet article a été publié il y a 8 ans 4 mois 6 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.
[Mise à jour du 11 janvier 2018] Merci de consulter l’article plus récent concernant le périmètre d’application de l’article 46 de la loi de finance 2018.
Je suis très étonné du relatif silence dans lequel ce texte de loi est en train de passer. Il faut dire que les diversions sont légions. C’est Philippe Pary, porteur du projet de logiciel libre de caisse enregistreuse Pastèque qui a lancé l’alerte il y a déjà pas mal de semaines.
Celle-ci est bien arrivée aux concernés, certaines communautés comme celle de Dolibarr ont d’ailleurs travaillé sur le sujet pour au moins faire un état précis du problème et évaluer les solutions techniques et juridiques possibles. Mais l’absence de réaction sur la liste du PlossRA sur laquelle pourtant se trouve bons nombre d’intégrateurs d’ERP open source m’interpelle cependant.
Inaltérabilité
C’est l’article 38 du texte de projet de loi qui introduit cette notion :
[…]Lorsqu’elle enregistre les règlements de ses clients au moyen d’un logiciel de comptabilité ou de gestion ou d’un système de caisse, utiliser un logiciel ou un système satisfaisant à des conditions d’inaltérabilité, de sécurisation, de conservation et d’archivage des données en vue du contrôle de l’administration fiscale, attestées par un certificat délivré par un organisme accrédité dans les conditions prévues à l’article L. 115-28 du code de la consommation ou par une attestation individuelle de l’éditeur, conforme à un modèle fixé par l’administration.[…]Le fait, pour une personne assujettie à la taxe sur la valeur ajoutée, de ne pas justifier, par la production de l’attestation ou du certificat prévu au 3° bis de l’article 286, que le ou les logiciels de comptabilité ou de gestion ou systèmes de caisse qu’elle détient satisfont aux conditions d’inaltérabilité, de sécurisation, de conservation et d’archivage des données prévues par ces mêmes dispositions est sanctionné par une amende de 5 000 € par logiciel de comptabilité ou de gestion ou système de caisse.[…]
Pour faire court, il faut une solution satisfaisant à ces conditions et si le commerçant n’a pas le petit papier c’est 5000€ par logiciel ou caisse. En gros tous les logiciels de gestion d’entreprises sont potentiellement impactés, propriétaires ou libres sans différence apparente.
Sauf que comme l’explique bien Philippe Pary dans un article présentant la problématique, cela revient à priver l’utilisateur de sa liberté N°3 octroyé par les logiciels libres : celle de modifier le programme. J’entends bien le contre-argument qui consiste à dire, que les entreprises ne modifient jamais elles-mêmes les logiciels, que cela ne changera donc rien…
Enfin si, car si vous installez un logiciel libre et que le client bidouille ou fait bidouiller le programme en question pour frauder et se fait pincer, vous êtes responsable aux yeux de la loi. N’oubliez pas que vous avez fourni le fameux papier qui atteste que le logiciel répond aux conditions d’inaltérabilité, de sécurisation, de conservation et d’archivage des données. Comment si ce n’est en « menottant techniquement » votre client pourrez-vous garantir cette inaltérabilité ?
Philippe Pary et Baptiste Carvello de l’April ont rédigé une proposition d’amendement au projet de loi qui a été transmise via le député du nord Bernard Roman. Aux dernières nouvelles, cet amendement ne sera même pas étudié…
Du souci pour rien ?
Je me demande souvent si je n’ai pas tendance à m’inquiéter pour rien. Les arguments existent :
- La mise en application est pour 2018, le gouvernement aura changé et peut-être détricoté ce qu’aura fait le précédent pour s’occuper ;
- Quid de toutes les sociétés qui font leurs factures sur Word ou Excel ?
- Quid des sociétés qui ont un logiciel en SAS hébergé a l’étranger comme Salesforce ?
- Quid des solutions SAS de facturation ?
- Quid des solutions internes de facturation ?
Pas mal de points et peut-être d’autres qui feront de ce texte, une couche supplémentaire et inapplicable dans les faits.
Il n’en demeure pas moins certain que le texte a été poussé par le lobby du logiciel propriétaire en vue d’évacuer le logiciel libre de ce segment du marché. Suite aux échanges de Philippe Pary avec des responsables du gouvernement, ce dernier réfléchit à la possibilité soit d’avoir une boîte noire, soit de devoir communiquer avec un tiers de confiance qui enregistrerait les données. Ce n’est pas gagné…
L’absence de comptabilité dans un ERP est souvent une raison pour laquelle certaines entreprises préfèrent se tourner vers autre une solution totalement intégrée. À l’avenir cet obstacle sera encore plus fort. D’ailleurs je pense que dés 2016, je serais confronté à la question par des prospects. Les éditeurs de solutions propriétaires vont s’empresser de communiquer sur cette nouvelle obligation légale. Je vous laisse imaginer le discours…
Certes près de 90% des entreprises de 1 à 49 salariés feraient appel à un expert-comptable selon l’Observatoire de l’Ordre des Experts comptables. Ce qui laisse un marché pour des ERP open source dépourvu de « vraie » comptabilité. Les utilisateurs se contentent au mieux de générer des exports pour les cabinets comptables disposant eux de logiciels « certifiés ». Par contre pour Philippe et ces caisses, c’est la fin du projet…
À l’heure où Dolibarr lance sa campagne de financement pour son module de comptabilité avancée, ce texte vient montrer encore une fois que le combat pour le logiciel libre est loin d’être gagné. Ces détracteurs, mieux organisés et donc dotés de moyens bien supérieurs n’ont pas fini de mettre des obstacles à son adoption.
Relativisons, rien n’est perdu, mais c’est loin d’être gagné 🙂
Il me semble impossible de garantir l’inaltérabilité d’un flux de données sans communiquer au minimum des hash avec un tiers de confiance ou avec des pairs (blockchain). Ce qui pourrait donner un avantage au logiciel propriétaire c’est l’idée que ne pas fournir le code source permet d’assurer l’inaltérabilité, ce qui est évidemment faux. La sécurité par l’obscurité ça ne fonctionne pas, et si l’administration en prend conscience alors le logiciel libre ne sera pas désavantagé.
Le blockchain fait effectivement parti des solutions qui est régulièrement évoquer pour gérer la notion d’inaltérabilité des données.
Pour moi la liberté de modifier le logiciel est toujours garantie. Par contre, cela demande à chaque client qui a modifié le logiciel de faire certifier ce « nouveau » logiciel !
Mais logiciel libre ou logiciel propriétaire, même combat, il me semble que l’on peut modifier le comportement d’un Sage ou d’un Navision ou encore d’un SAP et donc, par conséquent, l’argument de la fermeture du code ne fonctionne pas. Les progiciels de gestion sont faits, par nature, pour que l’on puisse les adapter aux processus de l’entreprise, donc que l’on puisse les modifier.
Par contre, pour les logiciels de caisses, c’est un peu moins vrai, je te l’accorde.
@Quentin : oui mais nous on est capable de le comprendre. La même problématique dans la bouche d’un Sage ou EBP c’est présenté très différemment et les utilisateurs se laisseront piéger par le discours « sécuritaire » et legistaltif, cela me semble une évidence malheureusement. Mais tu n’as pas tord non plus car c’est aussi une question de communication. Sauf que ce n’est pas la force du monde du logiciel libre…
En fait :
> un système satisfaisant à des conditions d’inaltérabilité, de sécurisation, de conservation et d’archivage des données
Qui revient à :
> un système satisfaisant à des conditions d’inaltérabilité […] des données
Je ne pense pas que ce soit le logiciel (et son code source) qui doive être inaltérable, mais bien les données.
On pourrait tout à fait imaginer un mécanisme pour qu’un logiciel, même libre, garantisse l’inaltérabilité des données.
C’est même déjà fait dans plein de logiciels, au moyen de hashes (Git), de signatures cryptographiques (un email avec GPG !), etc…
Effectivement, en ayant accès au code source, on peut supprimer la vérification, recompiler, et pouf, on peut altérer les données.
Mais après, on peut aisément vérifier que le logiciel a été modifié.
Par exemple, « rpm -V » verra qu’on a recompilé à la main et installé par-dessus le RPM. Si on a refait un RPM propre avec les modifications du code source, on verra bien qu’il ne vient pas du vendeur (les RPMS sont signés par clés GPG). Etc.
Bref, clairement, c’est une loi qui a le potentiel de nous filer beaucoup de boulot à nous autres développeurs (donc d’un côté je devrais peut-être pas me plaindre ?), mais ça va être du boulot bien chiant pour gérer tout ça, et dans le libre on va encore se taper des arguments sur le fait qu’on est moins sécurisés puisque notre code est ouvert et modifiable. D’un autre côté, c’est déjà un peu le cas, et donc je ne pense pas que ça soit la mort du logiciel libre de compta et de gestion de caisses.
Et très franchement, un logiciel propriétaire, ça se modifie aussi (regarde les gros logiciels commerciaux qu’on peut télécharger en versions pirates… bourrées de malwares). C’est plus compliqué, mais si le but est de gruger de quelques millions d’euros, le jeu peut en valoir la chandelle.
Bonjour, je réagis à ce passage :
« Enfin si, car si vous installez un logiciel libre et que le client bidouille ou fait bidouiller le programme en question pour frauder et se fait pincer, vous êtes responsable aux yeux de la loi. N’oubliez pas que vous avez fourni le fameux papier qui atteste que le logiciel répond aux conditions d’inaltérabilité, de sécurisation, de conservation et d’archivage des données. Comment si ce n’est en « menottant techniquement » votre client pourrez-vous garantir cette inaltérabilité ? »
Il me semble qu’une simple somme de contrôle sur le code fourni au client par l’entreprise, avec attestation, permettrait de le distinguer du code modifié qui pourrait être mis en œuvre pour tricher ensuite, sans pour autant que cela menotte qui que ce soit. Non ?
Ce texte de loi est à mon sens une bonne chose. Il suffit à l’éditeur de fournir une attestation individuelle comme quoi son logiciel répond aux conditions d’inaltérabilité etc. des données et c’est tout. c’est de l’auto-certification comme avec la norme CE ou d’autres normes. Je pense que ça coupera l’herbe sous le pied aux éditeurs de logiciels propriétaires qui font courir tout un tas de fausses rumeurs sur le danger des logiciels libres de gestion parce qu’on peut modifier leur code source, ils ne pourront plus mettre le doute dans l’esprit des clients en leur faisant confondre inaltérabilité des données et inaltérabilité du code source.
Ce serait aussi l’occasion pour les SSLL de fournir un deuxième certificat, attestant que le code source étant public, il ne contient pas de porte dérobée permettant d’accéder aux données confidentielles du client à son insu (transparence, sécurité, ne pas faire comme Volkswagen).
Est on obligé d’avoir une caisse enregistreuse numérique ?
Nombreuses sont les profession qui n’ont pas de caisse enregistreuse !
Peut ont encore communiquer à l’’administration fiscale une comptabilité papier ?
Si oui qu’est ce qui empêche d’avoir deux compta dont une pour les services fiscaux ? Et qu’est ce qui empêche de faire sa compta dans un tableur et d’en imprimer les pages pour en faire un « grand livre » comme il y a encore quelques décennies ?
Qui dans ce cas est responsable en cas de tricherie ? Microsoft car c’est avec Windows et Excel ?
Le papier peux se conserver bien plus longtemps que les données numérique et nul besoin d’un outils pour les examinées.
Ce support ne ne devrait donc pas être bannis. Dans ce cas il l’emporte sur le support numérique, et comme il ne faut pas d’organisme certificateur du papier et de l’encre, pourquoi en faudrait il un pour les logiciels ?
Dans ce même cas le responsable est la structure qui édite et fournis sa comptabilité !
Par ailleurs les doubles caisse ont la plupart été réalisée par des éditeurs n’ouvrant pas leur code !
Maintenant, si j’achète une voiture et que je la transforme, je dois passer par les mines (Certains ne le font pourtant pas ).
Si je construis une voiture c’est pareil !
Et pour la conduire je dois passer un permis de conduire.
Mais dans les deux cas si je dépasse la limitation de vitesse sur la route ce n’est pas le constructeur qui est en cause !
Si je cause un accident avec ma voiture de série trafiquée, et que c’est les modifications qui sont en cause, je suis le seul responsable ! Pas le constructeur.
Alors il peut y avoir une certification même pour le logiciel libre. Mais cette certification ne dois pas engager l’éditeur, mais seulement l’utilisateur !
Voila quelques arguments contre la loi, et donc mieux sensibiliser les députés qui votent la loi !
Quand a mobiliser les entreprises il ne faut pas trop y compter !
Par contre les associations peuvent êtres plus sensibles et donc se mobiliser puisqu’elles se mobilisent déjà normalement pour l’intérêt général ! Elle se mobiliseront d’autant plus si les outils opensource savent leur faire de belles propositions comme celle déjà intégré dans une proposition pour Dolibarr 😉
Si des milliers d’ado utilisent aussi comme proposé dans la stratégies, c’est aussi leurs parents qui pourraient êtres séduit pour adopter CRM/ERP … qui plus est Libre / Opensource ! C’est d’autant plus de poids d’utilisateurs qui peuvent créer un mouvement pour le libre / opensource comme pour contrer cette loi !
Encore faut il que les développeurs s’intéressent vraiment à ce type de stratégies et à l’intérêt général au lieu de s’intéresser à l’opensource comme d’autres font du greenwashing
Non, s’assurer que le code qui tourne sur une machine sous le contrôle de quelqu’un d’autre n’a pas été modifié, on ne sait pas faire.
De même, des données hashées ou signées ne sont inaltérables que si les hashs ou signatures en question sont enregistrés au fur et à mesure par un ou plusieurs tiers. Il est très simple de réécrire l’historique d’un dépôt Git, je le fais d’ailleurs régulièrement.
@Changaco : Il est simple de fournir un hash d’une version d’un logiciel. L’éditeur ne se porte garant que sur cette partie du logiciel car lui détient « la » version du hash. Si lors du contrôle, le hash est différent alors, c’est l’utilisateur qui est responsable. Si le logiciel est modulaire, alors seul la partie du code qui est certifiée est hashée. Si l’utilisateur veut installer un module qui permet de supprimer des écritures, c’est lui qui en prend la responsabilité.
Il me semble que le fait d’avoir un logiciel certifié ne garantie pas une comptabilité propre. Ce n’est pas parce que vous utilisez un logiciel comptable certifié que vous passez outre les contrôles.
Ce n’est parce qu’une entreprise fait appel à un comptable qu’elle peut se sentir hors de portée de ce projet de loi.
En effet, le plus souvent, l’entreprise utilise un logiciel de caisse ou gestion commerciale ou comptabilité, et périodiquement envoi ses écritures à son comptable. Les logiciels de l’entreprise doivent donc satisfaire des conditions d’inaltérabilité, de sécurisation, de conservation et d’archivage des données.
J’attends de voir les réactions des entreprises qui vont toutes devoir remplacer leurs logiciels et donc passer à la caisse (logiciels libres ou non), car cela nécessitera du temps, des prestations et dans le monde propriétaires, des licences…
A 3 millions d’entreprises en France, faites les calculs du nombre d’heures à dépenser et les coûts associés… on dépasse le milliard d’euros.
Concernant OpenConcerto (logiciel de gestion libre), on se pliera à ces exigences.
De notre point de vue, cette loi ne sert à rien, les fraudeurs trouveront toujours comment frauder.
Faites circuler les numéros de téléphone ou les emails des personnes à la tête de ce projet, nous avons une belle base de plus de 200 000 entrepreneurs qui ont téléchargé OpenConcerto et qui seront ravis de faire du bruit 🙂
> Il est très simple de réécrire l’historique d’un dépôt Git, je le fais d’ailleurs régulièrement.
Et ça n’altère en rien les données qui ont été enregistrées dans le dépôt.
Quand tu fais un « git rebase -i » pour réécrire ton historique, tu vas créer de nouveaux objets (blobs, trees, commits), mais les anciens n’ont pas été modifiés.
Éventuellement, les anciens vont être supprimés par le garbage collector, mais c’est un détail d’implémentation lié à git : il suffirait de ne pas avoir de garbage collector, et de ne jamais supprimer aucune donnée.
@Quentin On est tout à fait d’accord que l’éditeur n’est pas responsable des fraudes de l’utilisateur, je n’ai pas dit le contraire.
@bochecha Et pour empêcher la suppression des données il faut… un système de fichiers inaltérable. Retour à la case départ, Git n’a pas résolu le problème.
@Guillaume : quand j’ai dis à mon coiffeur qu’il devrait changer sa caisse pour une certifié sinon payé 5000€, j’ai cru que j’allais ressortir chauve 😀 !
Cette loi fait parti (au hasard les éthylotest et autre détecteurs de fumées) de celles poussées par des lobbies pour se générer de copieux marchés « réglementaires ». Et surtout, ce n’est pas leur faute, c’est l’état qui l’a fait 😉
Il est fort probable que cette loi sera amendées quand les entreprises réaliseront… Mais entre temps, elle va entretenir le FUD envers les logiciels libres dans le monde de l’entreprise… En cela elle est particulièrement nocive.
Un tweet à @CECKERT56 vaut mieux que 10 commentaires 🙂
@Philippe On est pas à coup bas de la part de Sage, Ciel, EBP, Cegid… ils sentent que nous grignotons leurs parts de marché. C’est bon signe.
Bonjour,
Le plus gros problème que nous ayons n’est-il pas que personne n’est en mesure de donner un sens précis à ce qui pourrait être voté. Tant que les décrets ne sont pas parus, même l’administration ne pourra faire que des suppositions. Evitons d’abonder sur les suppositions.
S’il faut prévoir des mécanismes qui empêchent la triche, il faudra intégrer cette fonction dans les logiciels et dans les bases de données. Si un tiers agréé doit intervenir il faudra comprendre comment. En fait, je ne serais pas surpris que tout cela accouche de peu de choses. N’oublions pas que la triche est déjà interdite, que publier un logiciel de triche est déjà interdit, que tripatouiller la base de données est déjà interdit.
Je pense que nous avons aujourd’hui le besoin d’un peu de clarté pour ne pas tout mélanger et nous agiter sans résultat.
Si nous ne savons pas ce que veut la loi, nous devrions quand même avoir une idée sur les aspects suivants :
– quel vocabulaire convient pour décrire la situation: on parle d’éditeur de logiciel libre, ne doit on pas plutôt considérer qu’il y a des auteurs ? Qui va alors jouer le rôle du tiers de confiance qui fait certifier une version ?
– pourquoi le fait de publier les sources sous licence libre nous pénaliserait-il ? Parce que ça permet de recréer des versions falsifiées ?
Même si la loi ne nous y contraignait pas, il faudra tôt ou tard se préoccuper du sujet.
@SISalp : Je te rejoins sur le fait que cette problématique devait un jour être abordée. Sinon la logique voudrait que ce soit celui qui met à disposition le logiciel qui certifie. Cela réglerait le problème des logiciels communautaire sans éditeur identifié.
Le fait que ce soit un logiciel libre n’est pas forcément disqualifiant dans le cas de réglementation contraignante.
Je prend un domaine que j’ai pas mal fréquenté celui de la pharma. il y a tout un tas de réglementations comme le CFR 21 Part 11 (oui là je me la pète 🙂 ) de la FDA américaine et qui concerne justement tous ces aspects informatique de validité et d’inaltérabilité des données. A ce que je sache cela n’a jamais disqualifié les logiciels libres effectivement. Et ce sont les intégrateurs qui doivent démontrer via des dossiers que leur outil est « compliant ». Le client doit pouvoir fournir ce dossier en cas d’inspection. Les éditeurs de logiciel du secteur fournissent d’ailleurs des dossiers « type » et la prestation pour les personnaliser au contexte du client.
Par contre pour les ERP que je connais comme Dolibarr, leur fonctionnement les disqualifieraient pour un usage avec ce type de réglementation. J’ai même un prospect en ce moment qui se lance dans la fabrication de dispositifs médicaux avec tout un tas d’obligations légales de traçabilités. Pour l’instant si Dolibarr va lui servir d’outil de gestion, la partie légale sera gérée par …. de l’archivage papier.
Un autre exemple l’archivage légale ou les éditeur de logiciel libre comme Maarch sont présents.
C’est donc plus le FUD, son impact commercial et le coût de mise aux normes qui m’inquiète et la capacité des communautés à se mobiliser pour proposer rapidement des contres-mesures claires et communiquer dessus.
@ Philippe La certification est une chose, la responsabilité en est une autre 😉 Telle mon exemple automobile
A ce propos constructeurs Auto et propriétaires se doivent d’avoir des assurances …
D’après ce que j’ai capté ce qui est en place ou se prépare serait que ce soit le constructeur qui serait responsable même si le client fait des conneries ! En droit ça pose des problèmes et même humainement.
Donc qu’il y ai le besoin d’une certification ok ! Et tant qu’a faire qu’elle soit aussi équitable en fonction des ventes
Mais en aucune manière le certifié ne doit être responsable de l’usage et des détournements possibles.
Sinon, je remarque que ton prospect utilise le moyen de pression que j’ai déjà évoqué : l’archivage papier 😉
Quand FUD envers le libre par les « proprio » … Si le libre continue de seulement s’agiter seul, il n’ira encore pas loin.
Par contre il pourrait contrer le FUD en même temps que se trouver des clients s’il sait séduire des utilisateurs, telle la proposition a Dolibarr.
Avec ils pourraient être autant de renforts pour faire pression / lobbyiser les élus … en même temps qu’indirectement ils pourraient mieux inciter les entreprises a utiliser du Libre 😉
Du reste ils sont les mêmes qui pourraient faire rejoindre un certain GIE , et qui pourraient aussi aider à financer / faire financer un autre projet connexe de Fond de Dotation.
Et je ne parle même pas des autres curseurs de la console de mixage d’une autre vision du libre / opensource
@ Philippe
Oui, tu vois bien le point que je soulevais. Ton exemple pharmaceutique est concret. Pour ma part je suis dans une période de réflexion sur Gnu Health et nous devons protéger des données médicales ou de sécurité sociale. On aussi les mêmes soucis quand les matières manipulées sont réglementées, leur traçabilité est une obligation légale. etc…
La solution complète consiste à certifier le logiciel et les procédures d’administration du serveur physique. Bien sûr, la liberté de garder ses données médicales confidentielles s’oppose à la liberté de faire ce qu’on veut du serveur.
En ce qui concerne les logiciels de gestion, libres ou privateurs, certains n’ont pas encore intégré des contraintes de ce type et proposent des fonctions « undo » dignes de républiques bananières. Par exemple :
– Un logiciel que je connais comporte un paramètre « permettre l’effacement des écritures » a été forké pour passer une certification analogue. 😉
– Un autre logiciel que je connais aussi n’a pas ce paramètre et garantit la non-altération des données par l’utilisateur (au sens strict). Toute annulation nécessite contre-passation.
Enfin, si j’administre les serveurs d’Al Capone et que je transforme la caisse enregistreuse en bandit manchot, il vaut mieux que je le fasse depuis les Bahama, certification ou pas.
Extrapolons ! la problématique est la même pour un site de e-commerce reposant sur une solution open-source. Car au final un prestashop, magento ou un Oscommerce ne sont t’ils pas des outils de gestion de caisse………
@frederpe A peu de chose prêt oui 🙂
Les logiciels de facturation et de comptabilité simples et limités seront-ils aussi concernés ? Je pense notamment à https://vosfactures.fr/ ?
Bonsoir,
Nous sommes distributeur et utilisateur d’un logiciel de comptabilité agricole « maison ».
Il répond « globalement » aux « conditions d’inaltérabilité, de sécurisation, de conservation et d’archivage des données » mais je doute qu’il soit accrédité par un organisme officiel bien qu’il réponde entièrement à nos besoins !
Quand je lis la phrase suivante « Lorsqu’elle enregistre les règlements de ses clients au moyen d’un logiciel de comptabilité ou de gestion ou d’un système de caisse », je me pose la question suivante : un logiciel de comptabilité qui ne gère pas la relation client ne sert pas directement à enregistrer le règlement d’un client. Est-il concerné par cet article ?
Merci pour vos réponses
Henry