La loi de finances 2016 en France dispose d’un article 88 qui vise à réglementer le secteur des logiciels d’encaissement.
Citons‐en la partie essentielle :
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 L115-28 du code de la consommation ou par une attestation individuelle de l’éditeur, conforme à un modèle fixé par l’administration.
Alerté au début de l’été 2015, votre humble serviteur a entamé depuis octobre 2015 une action vis‐à‐vis de cet article potentiellement nuisible au logiciel libre et qui entrerait en vigueur le 1er janvier 2018.
La coordination principale a lieu sur la liste comptabilite@ de l’April, liste ouverte à tous sans besoin d’adhésion à l’association.
TL;DR
Nous avons été reçus par Infocert, société de certification, et le Gouvernement. Nous avons reçu une écoute attentive. Les problèmes que nous soulevons ont été reconnus comme vrais. Le front est situé autour de la liberté de modification et de la notion d’éditeur d’un logiciel communautaire.
Aucun engagement concret n’a cependant été pris.
Où en étions‐nous ?
La dernière fois que je me suis exprimé en ce lieu, la loi n’était pas votée. Je n’avais rencontré personne, l’action se cantonnant à des contacts téléphoniques avec le cabinet du secrétaire d’État au budget.
Beaucoup des conclusions présentes dans les commentaires, renforcées par des échanges sur la liste comptabilité se sont avérées.
Accélération et préparation
Alerté par du remous sur Internet, le Gouvernement a pris contact. Un échange rapide a conclu à un engagement de rencontre en janvier, engagement qui s’est réalisé.
Je suis également rentré en contact avec Infocert, seul organisme proposant une certification en rapport à cette loi. Il y a eu deux rencontres fin janvier.
Une intervention dans l’Écho des gnous, émission FM sur radio Campus Lille, avait mobilisé la communauté.
Les échanges sur comptabilite@ mais, aussi surprenant que ce soit, également sur LinuxFr.org, ont été productifs.
Un article sur Numerama a donné de la visibilité au sujet, produisant des retours.
Je me suis mis en rapport avec l’April qui, mixé aux analyses juridiques de l’avocate de Scil (éditeur du logiciel Pastèque), a été indispensable sur le plan juridique et politique.
Rencontre avec Infocert
Infocert confirme : la norme Logiciel de gestion et d’encaissement a précédé la loi.
Infocert reconnaît qu’en l’état, les sujets du logiciel libre, du cloud et des tablettes (dans cet ordre) sont à creuser. Infocert a indiqué que la certification serait revue aux lumières des précisions apportées par le Gouvernement autour de la loi.
Infocert invite les acteurs du monde libre à rejoindre son Club Access (ce n’est pas gratuit) afin de débattre du sujet.
Rencontre avec le Gouvernement
L’équipe de l’April et moi‐même avons été reçus au ministère des finances. Les participants du côté de l’État soulignent a minima une considération sérieuse pour le sujet.
Nous venions avec trois points principaux et des sujets connexes.
Les trois points principaux :
- Protection des éditeurs de logiciels libres en cas de dévoiement du logiciel par un utilisateur. A priori, ce point est déjà assuré par plusieurs principes juridiques. Pour résumer, un constructeur de vélos ne sera jamais mis en cause pour un problème lié aux bricolages d’une personne sur son vélo.
- Protection du droit à modifier un logiciel : la loi ne doit pas empêcher un utilisateur d’apporter des modifications à un logiciel, y compris aux sections concernant les données. Nous avons émis des propositions, elles ont été prises en note.
- Proposition de télétransmission des données en temps réel (déclarations TVA, signatures comptables) : cela a été repoussé à après la mise en œuvre de la loi actuelle. Ce point est une manœuvre pour réduire la complexité de la vérification de l’intégrité des données locales dans un environnement logiciel totalement ouvert.
Les sujet connexes :
- Définition de la notion d’éditeur de logiciel. Rien n’existe dans la loi à ce propos, cela a été reconnu. Ce point est pourtant plein de conséquences pour les projets libres communautaires et, mais on s’en fout, pour les systèmes d’information propriétaires complexes avec plusieurs intervenants.
- Question du commerce électronique : est‐il concerné ? Si oui, la masse de personnes concernées serait énorme.
- Retour sur la loi de 2013 de lutte contre la fraude, qui contient des dispositions récusées par l’April.
- Retour sur le rejet de la priorité au logiciel libre.
Nous n’avons pas abordé la question de la conservation de données privées. Nous passerons le sujet à la Quadrature du Net quand cette dernière aura un peu plus d’air ; l’état d’urgence est toujours l’actualité.
Le Gouvernement lancera prochainement une consultation dans le but de clarifier tous les points flous de la loi d’ici au mois de juin 2016. Nous l’avons invité à le faire en ligne.
Piste bonus
Nous en sommes restés coi : un de nos interlocuteurs, inspecteur général des impôts, nous a dit avoir lu les commentaires de la dépêche LinuxFr.org précédente.
Aller plus loin
- Article de loi (118 clics)
- La liste comptabilité de l’April (158 clics)
- Pastèque (logiciel concerné, un peu d’auto‐promo…) (165 clics)
- Dépêche précédente : Projet de loi de finances FR 2016 : interdiction des logiciels libres de compta (131 clics)
- Numerama : Bercy pourrait rendre illégal le logiciel libre pour la comptabilité (124 clics)
# Merci!
Posté par Sébastien Bonnegent . Évalué à 3.
Merci pour le résumé de la situation, cela permet d'enlever un peu de flou des premières annonces sur le sujet. Espérons que le logiciel libre soit correctement pris en compte.
Je trouve l'idée de télétransmission très intéressante.
Bon travail :)
Note: il doit manquer "AUSSI" dans la phrase suivante:
Les échanges sur comptabilite@ mais, AUSSI surprenant que ce soit, également sur LinuxFr.org, ont été productifs.
[^] # Re: Merci!
Posté par feth . Évalué à 2.
Je trouve l'idée de télétransmission séduisante aussi, d'autant qu'elle limite la fraude fiscale (on peut imaginer un acquittement des transactions par signature de Bercy).
Mais que faire en cas de panne réseau ?
[^] # Re: Merci!
Posté par Elephant (site web personnel) . Évalué à 0.
Les pannes réseau seraient des événements à remonter comme meta-information.
Des pannes trop régulières seraient évidement quelque chose de nature à amener un simple contrôle de routine, je suppose.
[^] # Re: Merci!
Posté par Sébastien Bonnegent . Évalué à 0.
Ce type de problème parait assez facile à résoudre avec un système de spool, un peu comme un serveur de messagerie d'ailleurs.
Pourquoi utiliser la norme XMPP pour cela :)
[^] # Re: Merci!
Posté par cbri . Évalué à 1.
La télétransmission n'ai pas obligé d'être synchrone. SESAM/Vitale est un système de télétransmission asynchrone basé sur SMTP.
Si il y a une panne réseau ponctuelle, on refait la télétransmission le soir suivant. Pour certaines professions comme les pharmaciens, si la télétransmission n'est pas faite, ils ne sont pas payés. Donc ils feront tous pour la faire régulièrement et fréquemment.
# inaltérabilité ??
Posté par KiKouN . Évalué à 3. Dernière modification le 04 février 2016 à 21:07.
Vous avez vu Infocert. Franchement, je leur demanderai bien comment ils faut pour certifié un logiciel ( un format de données plutôt ^ ^ ) qui soit capable d'assurer l'inaltérabilité de ces données ?
Je ne vois pas comment l'on peut faire sans fournir ces données chiffrées ou non à un tier de confiance ou en utilisant une technologie de type blockchain ?
[^] # Re: inaltérabilité ??
Posté par bunam . Évalué à 0.
Je pensais aussi à la blockchain (cf http://framablog.org/2016/01/30/la-blockchain-au-dela-du-bitcoin/ un des rares bons articles de framasoft ;p)
par contre le problème c'est qu'on va tout savoir des activités de tous le monde…
Il manque une notion "visible par" dans ce système non ?
[^] # Re: inaltérabilité ??
Posté par KiKouN . Évalué à 2.
On n'est pas obligé de publier la donnée exacte. On peut très bien publier qu'une signature ou une donnée chiffrée.
La notion de "visible par" peut être obtenu un publiant une donnée chiffrée avec la clé publique de celui qui a le droit de le lire.
Quoi qu'il en soit, pour rendre inaltérable une donnée, il faut la publier un minimum et le plus tôt possible.
Cette notion de temps peut aussi poser problème, car l'on peut très bien modifié la donnée avant de la publier.
[^] # Re: inaltérabilité ??
Posté par Liorel . Évalué à 2.
Mais en fait, j'ai du mal à voir en quoi l'usage d'une blockchain garantit l'intégrité des données.
Qu'est-ce qui m'empêche de faire payer un produit 10€, et d'écrire sur la blockchain, dès l'instant de la transaction, que j'ai réalisé une transaction pour 9€ ? Je ne pourrai plus revenir dessus, certes, mais j'ai déjà écrit une transaction erronée en premier lieu.
Sauf si le client (ou sa banque) écrit en même temps que moi sur la blockchain, je ne vois pas où ça coince. Mais là on est dans le tiers de confiance, pas dans la blockchain.
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: inaltérabilité ??
Posté par KiKouN . Évalué à 2.
La blockchain n'est juste qu'un tiers de confiance publique. Si tu garde ta blockchain rien que pour toi, personne ne peut la vérifier.
Le problème, ce n'est pas l'écriture dans le logiciel comptable mais l'argent liquide qui permet de ne pas laisser de trace. Si tu supprime le liquide, il n'y a plus de problème, car c'est les banques ou les blockchains qui vont jouer le rôle de tiers de confiance.
[^] # Re: inaltérabilité ??
Posté par Liorel . Évalué à 1.
Ça j'ai compris, mais qu'est-ce qui m'empêche de mentir à la blockchain, même publique ? La blockchain ne fait qu'archiver que tel jour, telle heure, je lui ai dit "j'ai encaissé 9€". Mais si en vrai j'en ai encaissé 10, quel moyen a l'autorité de contrôle de le vérifier ?
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: inaltérabilité ??
Posté par Hobgoblins Master (Mastodon) . Évalué à 2.
Si paiement en liquide, aucune, si paiement électronique, c’est l’ID de transaction bancaire qui est transmis à la blockchain, donc l’administration peut très simplement vérifier auprès de ta banque que la transaction est bien du même montant.
[^] # Re: inaltérabilité ??
Posté par ludovic2409 (site web personnel) . Évalué à 0.
Il me semble que le projet de loi oblige également le commerçant à fournir un ticket de caisse.
[^] # Re: inaltérabilité ??
Posté par cbri . Évalué à 1.
La loi oblige déjà le commerçant à fournir un ticket de caisse (regarde au supermarché).
[^] # Re: inaltérabilité ??
Posté par Elephant (site web personnel) . Évalué à 1.
la loi oblige le ticket de caisse sur demande du client si inférieur à 26€, obligatoire si supérieur à 26€. Obligatoire dans tous les cas dans la restauration
[^] # Re: inaltérabilité ??
Posté par Larry Cow . Évalué à 2.
Le fait qu'éventuellement tu gères aussi ton stock par la même blockchain? Je suis une quiche en compta, mais il me semblait que c'était un peu le but de la double écriture : permettre à tout moment de vérifier que ce qui sort en bien/service correspond à ce qui rentre en tréso (et inversement).
Si tu ne "suis" que les entrées d'argent, effectivement ça ne va pas le faire. Mais c'est déjà le cas aujourd'hui, et il me semble même que c'est à ça que servent les inventaires.
[^] # Re: inaltérabilité ??
Posté par KiKouN . Évalué à 2.
Bin rien. C'est pour cela que je ne trouve pas l'utilité de faire réaliser cette tâche ( l'inaltérabilité ) aux logiciels de compta. Car ce qui est actuellement altérable, c'est le moyen de payement, le liquide et le troc en particulier. Si le moyen de payement est vérifié par un tier, ce que tu mets dans ta compta, on s'en fout. On connaît tes entrées/sorties. Si tu te gourre dans ta compta, c'est ta faute.
[^] # Re: inaltérabilité ??
Posté par Hobgoblins Master (Mastodon) . Évalué à 3.
Pour garantir que toute modification postérieure d’une transaction soit détectée lors d’un audit, ne serait-il pas suffisant d’associer une estampille temporelle certifiée incluant la signature de la transaction son № de séquence ?
Ça n’empêche pas l’annulation « immédiate » d’une transaction, ni sa suppression future, mais les lignes vides se verraient plus facilement.
[^] # Re: inaltérabilité ??
Posté par KiKouN . Évalué à 3.
Il faut donc un tiers encore une fois. Cela se resume à faire signer un hash ou un document par un tiers.
[^] # Re: inaltérabilité ??
Posté par Hobgoblins Master (Mastodon) . Évalué à 2.
Il y a des solutions (boite noire onéreuse) pour le faire en local, ça à également l’avantage de n’utiliser que de l’infrastructure existante, de toute façon, il devient de plus en plus difficile d’encaisser un paiement (hors liquide) sans connexion, les TPE sont connectés en permanence.
Il est peut-être possible également en utilisant TOTP et HOTP simultanément (ou dérivé) depuis un token USB dont la clé est détenu par l’autorité de contrôle de rendre vérifiable et le moment et la chronologie des transactions. Du coup on est complètement hors connexion (sauf pour les phases d’initialisation ou synchronisation du token).
[^] # Re: inaltérabilité ??
Posté par KiKouN . Évalué à 2.
Mais, boite noire ou clé USB ( une yubikey ou autre doit peut-être même pouvoir faire cela ), elle sont fourni par un tiers de confiance. Il déporte juste sa solution au plus près.
# Merci
Posté par Nibel . Évalué à 1.
Merci pour votre action.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
# vocabulaire
Posté par bobby93 . Évalué à 5.
Bonjour,
pourquoi parler de "l'organisme" Infocert alors qu'il s'agit d'une SARL privée ?
On n'est pas ici en présence d'une étude plus ou moins mal réalisée de l'intérêt public, mais juste d'une tentative de cartélisation du logiciel professionnel par une poignée de crapules ayant probablement corrompu les bonnes personnes !
[^] # Re: vocabulaire
Posté par barmic . Évalué à 4.
Du calme moussaillon ! C'est probablement plus une méconnaissance de la technique que de la malveillance.
La problématique de cette loi est tout à fait pertinente et la réponse assez logique. Il faut juste trouver un moyen pour faire cohabiter le LL avec cette problématique.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: vocabulaire
Posté par prof38 . Évalué à 4.
Bonjour, la remarque concernant Infocert est très juste… et sinon pour avoir bossé longtemps chez un gros éditeur de logiciel français, j'ai bien vu et compris comment se passait les procédures de certification de logiciels de comptabilité… pas de corruption non puisque une société privée paye une autre société privée en toute légalité; ensuite un bon resto peut aplanir certains points d'achoppement…
[^] # Re: vocabulaire
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
J'ai remplacé organisme par société dans la dépêche pour clarifier ce point.
# Une norme comme SAF-T ne serait-elle pas suffisante?
Posté par Julien Béti (site web personnel) . Évalué à 8.
Pour une implémentation au Portugal, nous avons du mettre en place une norme internationale SAF-T de transmission des données de facturation à l'administration fiscale portugaise:
Le principe est assez intéressant, puisqu'il se base sur un Hash (clé publique/privée) basé sur:
Il semblerait que la France ai déjà adhéré à cette norme, imposer sa mise en place ne serait-elle pas suffisante?
[^] # Re: Une norme comme SAF-T ne serait-elle pas suffisante?
Posté par Elephant (site web personnel) . Évalué à 2.
Merci pour ces liens. Je devais justement creuser le sujet de ce qui se fait au Portugal, j’en gagne du temps
[^] # Re: Une norme comme SAF-T ne serait-elle pas suffisante?
Posté par Laurent Destailleur (site web personnel) . Évalué à 1.
Tu parles d'un "Hash (clé publique/privée) basé sur …".
Un hash étant un code transformant un chaine en une autre sans clé particulière, que signifie un "Hash (clé publique/privée)" ?
Expert ERP CRM Open Source et (Dolibarr ERP CRM, Odoo, ...)
# Et?
Posté par Zenitram (site web personnel) . Évalué à -9.
Mais au final, c'est quoi le problème?
Parce que quand je lis la dépêche, j'ai l'impression que tu confirmes (sans le dire explicitement) que vous avez fantasmé sur des problèmes imaginaires et que le gouvernement n'a fait que expliciter que c'était imaginaire et va l'expliciter aussi dans le texte pour vous faire plaisir et on n'en parle plus.
C'est la conclusion?
Ca n'a pas dû aider à vous faire prendre au sérieux sur autre chose que des problèmes imaginaires…
[^] # Re: Et?
Posté par Elephant (site web personnel) . Évalué à 1.
Le problème est reconnu par nos interlocuteurs. Donc au pire, ça veut dire qu’à Infocert et au gouvernement aussi ça fantasme.
We are all mad here, comme on dit
[^] # Re: Et?
Posté par Crao . Évalué à 1.
Je pertinente Zenitram. Vous confirmez ce qu'on savait déjà : il n'y a pas la moindre interdiction du logiciel libre. Votre réunion aurait pu être faite par n'importe quelle société éditrice (certaines ont très probablement déjà fait cette démarche) pour éclaircir certaines zones de flou, le truc qui se fait dans tous les domaines.
Après rappeler l'existence du logiciel au gouvernement c'est très bien. Par contre il va falloir vous habituer à ce dans un cadre réglementaire n'importe qui ne puisse plus faire n'importe quoi. Et ça vaut pour les logiciels libres comme pour les autres.
[^] # Re: Et?
Posté par Elephant (site web personnel) . Évalué à 1.
Il y a bien un risque. Lisez ce que j’écris. Si ce n’est pas clair, demandez des précisions.
[^] # Re: Et?
Posté par Crao . Évalué à 2.
J'aimerai vraiment qu'on me dise où est le risque d'interdiction du logiciel libre.
# Le fichier numérique non modifiable
Posté par Benoît Sibaud (site web personnel) . Évalué à 3. Dernière modification le 13 février 2016 à 12:08.
Article NextINpact: Un décret pour la mise en ligne de documents publics par les collectivités locales
Décret n° 2016-146 du 11 février 2016 relatif aux modalités de publication et de transmission, par voie écrite et par voie électronique, des actes des collectivités territoriales et des établissements publics de coopération intercommunale
« la commune choisit de publier sous forme électronique (…) sur son site internet (…) sous un format non modifiable »
J'ai du mal à voir ce que « non modifiable » signifie dans le contexte hormis « PDF que l'on dira-méthodeCoué pas modifiable ». Mais savoir ce que veut dire « non modifiable » dans ce décret pourrait aider pour l'« inaltérabilité » évoquée dans le sujet de cette dépêche.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.