Loi de finances 2016 en France : des nouvelles du front

Posté par (page perso) . Édité par Davy Defaud, Benoît Sibaud et ZeroHeure. Modéré par Xavier Claude. Licence CC by-sa
37
4
fév.
2016
Communauté

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 :

  1. 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.
  2. 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.
  3. 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.

  • # Merci!

    Posté par (page perso) . É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 (page perso) . É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 (page perso) . É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 (page perso) . É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 . Évalué à 1.

        Mais que faire en cas de panne réseau ?

        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 . Évalué à 3. Dernière modification le 04/02/16 à 21:07.

    un système satisfaisant à des conditions d'inaltérabilité

    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 . É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 . É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 . É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 . É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 . É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 (page perso) . É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 (page perso) . É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 . Évalué à 1.

                    Il me semble que le projet de loi oblige également le commerçant à fournir un ticket de caisse.

                    La loi oblige déjà le commerçant à fournir un ticket de caisse (regarde au supermarché).

                    • [^] # Re: inaltérabilité ??

                      Posté par (page perso) . É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 . É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 . É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 (page perso) . É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 . Évalué à 3.

        Dans la pratique, l’obtention d’un certificat d’horodatage nécessite de faire appel à une autorité de certification des temps.

        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 (page perso) . É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 . É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 (page perso) . Évalué à 1.

    Merci pour votre action.

    http://www.perruweb.com/

  • # vocabulaire

    Posté par . É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 . É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.

      Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

      • [^] # Re: vocabulaire

        Posté par . É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 (page perso) . É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 (page perso) . É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:

    • Date de la facture
    • Date de la la génération du hash
    • Montant total de la facture
    • Hash de la facture précédente

    Il semblerait que la France ai déjà adhéré à cette norme, imposer sa mise en place ne serait-elle pas suffisante?

  • # Et?

    Posté par (page perso) . É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?

    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.

    Ca n'a pas dû aider à vous faire prendre au sérieux sur autre chose que des problèmes imaginaires…

    • [^] # Re: Et?

      Posté par (page perso) . É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 . É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 (page perso) . É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 . É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 (page perso) . Évalué à 3. Dernière modification le 13/02/16 à 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 à ceux qui les ont postés. Nous n'en sommes pas responsables.