Je vous propose ici un résumé concernant l'article 88 de la loi française de finances pour 2016 concernant les logiciels de gestion et de comptabilité.
En décembre 2015, la loi de finances pour l'année 2016 a été votée. Son article 88 « dispose que les assujettis à la taxe sur la valeur ajoutée (TVA) doivent à compter du 1er janvier 2018 être équipés d'un système de caisse sécurisé ». La formule est celle de la DGFIP (Direction Générale des FInances Publiques).
Cette obligation se traduit dans les grandes lignes par le respect des « conditions d'inaltérabilité, de sécurisation, de conservation et d'archivage des données » ainsi que par le jeu de la responsabilité essentiellement basé sur un système de certification/ attestation obligatoire.
Une dépêche avait alors été publiée pour faire part de craintes sur les effets de cet article sur les logiciels libres; la disposition pouvant clairement résulter, de fait, dans l'interdiction des logiciels libres de caisse.
La deuxième partie détaille les actions entreprises (rencontres, courriers) et l'évolution de la situation.
En janvier 2016 l'April (Frédéric Couchet, Jeanne Tadeusz et moi même) et Philippe Pary (Société Scil) avions rencontré des membres de la DGFIP. Les éléments clefs qui sont ressortis de cette rencontre étaient que l'administration fiscale n'était pas opposée en soi au logiciel libre, ils se sont montrés réceptifs aux problèmes soulevés, qu'il était important de mieux définir la notion d'éditeur (à laquelle est attachée la responsabilité) et comment assurer les conditions d'inaltérabilité, de sécurité, de conservation et d'archivage des données.
Fin mars la DGFIP a fait un « appel à remarques » sur son projet de commentaire au BOFIP de l'article 88. Clôt le 29 avril. Celui-ci, bien sûr perfectible, montre un clair pas en avant vers les logiciels libres. Les inquiétudes n'ont pas été ignorées. Pour rappel, le BOFIP ou Bulletin Officiel des FInances Publiques a valeur de doctrine opposable à l'administration fiscale. Il s'agit donc d'un texte essentiel dans l'application de la loi de finance et donc sur l'étendue et la nature des obligations qui pèseront sur les « éditeurs » de logiciels de caisse, notamment libres.
Philippe Pary (société Scil, éditrice du logiciel de caisse Pastèque), et Baptiste Simon (Libre Informatique SCRL) ont co-signé une réponse à cet appel (en pdf) au nom du Syndicat Professionnel des Éditeurs de Logiciels Libres (SYNPELL).
Le document co-signé exposant clairement les différents points de vigilance et d'inquiétude, je me permets ici de vous en proposer un simple résumé des points essentiels :
Conditions d'inaltérabilité, de sécurisation, de conservation et d'archivage des données :
- Notions définies de manière trop floue.
- Il n'existe aucune méthode 100% fiable scientifiquement pour garantir ces conditions.
Système de certification, l'enjeu du lien de solidarité :
- Pour rappel il s'agit d'une certification de conformité du logiciel à la loi. Peut être délivrée par un organisme, ou par l'éditeur qui atteste de cette conformité (en engageant sa responsabilité).
- Le SYNPELL appelle à une certification directe par l'administration fiscale, et non déléguée à un organisme privé.
- Le syndicat critique également l'obligation de détenir un code NACE (~ le champ d'activité) spécifique à l'édition de logiciel de caisse pour auto-attester de la conformité de son logiciel, et/ou des modifications effectuées sur celui-ci.
- Cela est en lien direct avec un aspect positif du BOFIP qui précise que l'« éditeur » est soit le concepteur d'origine, soit le dernier intervenant qui a effectué une modification liée aux conditions d'inaltérabilité, de sécurité, etc. Ce dernier point est particulièrement important dans la mesure où il autorise la modification des logiciels sans faire porter une responsabilité « infinie » aux éditeurs. L'attestation de conformité s'éteint si la partie qu'elle concerne est modifiée.
Définition du logiciel libre :
- Le projet de commentaire au BOFIP définit un logiciel libre comme étant « librement paramétrable ». La réponse du SYNPELL rappelle la véritable définition, plus précise, basée sur les 4 libertés.
Nous sommes à présent dans l'attente de la publication officielle du BOFIP sur la loi de finances 2016. En espérant que ces différentes remarques auront été prises en compte.
Aller plus loin
- article 88 de la loi de finance pour 2016 (344 clics)
- Dépêche de décembre 2015 sur l'article 88 (155 clics)
- Site du SYNPELL (208 clics)
# petite faute de frappe
Posté par puyopuyo . Évalué à 3.
Dans la dernière phrase il y a écrit "financse" à la place de "finances".
[^] # Re: petite faute de frappe
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
# blockchain
Posté par Nicolas Boulay (site web personnel) . Évalué à 0.
Il existe un moyen, c'est la blockchain. Il doit être possible d'injecter les données comptables dans le système ethereum.org. Mais c'est en gros 80€/Mo d'écriture.
"La première sécurité est la liberté"
[^] # Re: blockchain
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 7.
"Bonjour madame. Alors 54,50 € s'il vous plait. Ah. Attendez. Je n'ai plus de connexion internet. La caisse ne veux plus encaisser. Désolé. Pouvez-vous revenir plus tard ? (grmlmlml faut encore que je rappel "internet by Orange")
[^] # Re: blockchain
Posté par EauFroide . Évalué à 2. Dernière modification le 14 mai 2016 à 17:41.
Ce troll fonctionne aussi avec MasterCard, Visa, etc (on a justement eu le coups a Troll et legend) :P
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: blockchain
Posté par judicael . Évalué à 0.
Je plussoie. Et plus généralement, des moyens à base de crypto (et des moyens globalement relativement simples). Avec un checksum cryptographique envoyé à un tiers de confiance à chaque transaction/chaque seconde/chaque minute/chaque jour suivant ce qu'on veut, on peut assez facilement assurer que toute altération des données est détectée. (Et on peut même le faire tout en gardant la confidentialité des données sans difficulté majeure AMHA.)
[^] # Re: blockchain
Posté par Elephant (site web personnel) . Évalué à 3.
Ce serait possible si le client était également participant de la blockchain. Mais c’est compromis ; on ne peut pas raisonnablement exiger d’un client qu’il installe un logiciel pour faire ses achats chez son boulanger :)
Du coup, seul le commerçant est seul émetteur de ses signatures. Un simple système de télétransmission de signatures chaînées aux impôts sera aussi efficace.
J’avais proposé cette mesure, elle a été écartée car jugée trop avant-gardiste et pouvant être de nature à susciter une opposition des utilisateurs (commerçants) comme des éditeurs (qui ont déjà du mal à mettre leurs logiciels vieillissants en conformité)
[^] # Re: blockchain
Posté par zebul0n (site web personnel) . Évalué à -2.
Quand tu dois déclarer ta TVA ou ton acompte d'IS, tu as déjà le droit à un "Le service est actuellement très demandé. Merci de réessayer plus tard …"
Les dates de déclarations des revenus des particuliers sont étalées par zone pour soulager leurs serveurs asthmatiques, l'autoscaling c'est pour 2045.
Alors, leur télé-transmettre quoi que ce soit, c'est déjà bien ambitieux !
[^] # Re: blockchain
Posté par Kerro . Évalué à 6.
Montre nous comment tu gères avec un budget raisonnable 1 million d'utilisateurs dix soirées de suite alors que les 354 autres jours c'est dodo.
[^] # Re: blockchain
Posté par zebul0n (site web personnel) . Évalué à 5.
La réponse est dans la partie que tu as tronquée : l'autoscaling …
Tu fais tourner 200 machines pendant 10 jours, et 20 les 354 autres.
Tu sais le cloud souverain, et je pense que 150 millions d'euros, c'est assez raisonnable comme budget.
D'autant plus qu'en fait les 354 autres jours, c'est pas dodo justement, c'est les pros qui enregistrent leurs acomptes TVA, IS. Et même là ça marche pas.
Et les heureux devant se taper les "Déclarations Européennes de Service" à effectuer sur https://pro.douane.gouv.fr/ avec de préférence je cite : "Mozilla 1.6 / IE 5.0 / Safari 1.0" ne jubilent certainement pas à l'idée de devoir s'interfacer avec une administration.
Confier un système de télétransmission de signatures chaînées à l'administration, c'est de l'hérésie !
[^] # Re: blockchain
Posté par Kerro . Évalué à 1. Dernière modification le 14 mai 2016 à 18:06.
1 - tu ne réponds pas à la question : comment fais-tu cela avec un budget raisonnable. Et sans que ça foire. Mettre « autoscalling » dans une phrase n'apporte pas magiquement de solution.
2 - tu as donc une solution pour multiplier par 10 une infra durant quelques jours sans que ça coûte une fortune. Dès que tu montes ta boîte, tu es à peu près certain d'être riche dans les mois qui suivent.
Quelque chose me dit que c'est plutôt 400 machines en temps normal, et 4000 en pointe, le tarif n'est pas tout à fait le même (aucune idée des vraies quantités. Par exemple pour pôle emploi c'est 4000 serveurs au quotidien).
Ton commentaire précédent est basé sur le fait qu'il y a une forte augmentation lors des déclarations de revenus. Tu ne peux pas changer ton argument à chaque message.
[^] # Re: blockchain
Posté par zebul0n (site web personnel) . Évalué à -1.
Parce que je ne sais pas ce que serait un budget raisonnable pour la collecte de l'impôt et que je ne sais pas ce que ça coute actuellement. Je sais juste que l'état collecte plus de 280 milliards d’euros des recettes fiscales nettes, il doit y avoir moyen de dégager un budget pour le collecter.
Ben, ça foire déjà, c bien le problème …
Ben, par exemple, Pole Emploi, avec 4000 machines, ils sont pas foutus d'enregistrer les demandeurs d'emploi sans que ça merde, je viens juste d'y aller pour tester : http://imgur.com/V1mc8vZ
Si des boites privées merdaient comme ça tout le temps, ça serait considérés anormal, mais avec les services de l'administration, c'est usuel. Alors, je sais pas ou passe le budget et ce qu'est un budget raisonnable pour ce genre d'institutions, vraiment aucune idée.
Mon commentaire précédent, c'était :
C'était dans mon premier message, tu tronques bien.
[^] # Re: blockchain
Posté par Zenitram (site web personnel) . Évalué à -1.
tu loues des serveurs "cloud" chez OVH (c'est en France et peuvent s'engager sur la confidentialité), OVH se chargeant de louer à d'autres les autres jours de l'année. Ca fait quand même quelques années que la gestion des pics existent tu sais…
Mais ceci dit en passant, on parle de remplir un bête bordereau électronique avec quelques divisions et soustractions, que ma machine est capable de faire des millions de fois par seconde. sérieux, il y a quand même un problème chez les gars qui pondent leur info (et qu'on me dise pas que c'est "difficile", je sais comment ça marche pour être pris par les contrats de ce type, ça n'a rien à voir avec le prix et les perfs).
Comprend pas : les machines doivent être dédiées à une tache? On ne t'a jamais enseigné la virtualisation, le déploiement rapide, qui fait que les machines peuvent faire d'autres choses 10 minutes après qu'on en ai plus besoin?
C'est un peu soit foutage de gueule soit hibernation depuis 10 ans.
[^] # Re: blockchain
Posté par oinkoink_daotter . Évalué à 2. Dernière modification le 16 mai 2016 à 15:52.
Amazon y arrive bien pour passer les fêtes de fin d'année, et à une toute autre échelle.
Après c'est comme tout projet de SI, on fait des pilotes et on teste avant la mise en prod, pour ne pas déployer n'importe quoi à la porcasse au dernier moment.
Pour la rentabilité, ça se calcule assez simplement, et c'est le fond de commerce des fournisseurs de cloud…
… C'est un peu le fond de commerce de n'importe quel fournisseur de cloud, absorber des pics de charge sans que ça coûte x*le TCO d'une machine à l'année.
Mais ça suppose que l'appli soit un minimum agile…
Pour paraphraser Zebul0n, on a cloudwatt et numergy qui seraient de bons candidats.
[^] # Re: blockchain
Posté par Kerro . Évalué à 2.
Un « légère » différence est que lorsqu'à Amazon multiplie par 10 ses visites, ça multiplie par 10 ses revenus. Ils seraient d'ailleurs ravis d'être obligés d'avoir 100 fois plus de serveurs. Ce qui n'est pas du tout, mais alors vraiment pas du tout, le cas de la DGFIP.
Et puis Amazon, à ma connaissance, fait tout en interne.
?! t'es sérieux là ? Les Régis du cloud…
Clairement tu parles d'un domaine que tu ne connais pas (pas la peine de me dire que c'est ton job au quotidien : ça ne prouve pas que tu t'y connaisses).
[^] # Re: blockchain
Posté par oinkoink_daotter . Évalué à 2.
So what ? La question est de savoir si globalement, utiliser du PAAS (même de matière partielle) n'est pas moins chère que que de maintenir à plein temps toute une mégachiée de serveurs utilisée pendant trois semaines par an ? Même pour amazon, le but c'est de dépenser le moins possible en infra pour s'assurer le max de marge.
Si l'exemple d'Amazon ne te plaît pas, tu remplaces avec n'importe quel vendeur de ecommerce qui a des gros pics d'activités dans l'année. Rue du commerce, FNAC, vente privée, que sais-je. Ca m'étonnerait que tous ces gens fassent ça avec une infra à la papa <3.
C'est à peu près le seul intérêt du PAAS : le besoin temporaire.
Ca dépend comment tu valorises l'exigence de confidentialité. As-tu besoin d'une garantie de localisation de tes données et d'une indépendance par rapport au patriot acts et aux gag orders. Les déclarations de patrimoine c'est bancable et concerne des résidents français, donc la question peut se poser.
A par le coût des infrastructure, as-tu des éléments pour dire que techniquement, ça ne marche pas ?
Non, mon job, c'est de m'assurer que ces choix soient faits en connaissance de cause.
[^] # Re: blockchain
Posté par wilk . Évalué à 1.
https://blogs.oracle.com/Oracle-France/entry/la_cnaf_d%C3%A9mat%C3%A9rialise_la_prime
Et encore, c'est en Java, tu réécris tout ça en Go pour diviser par 10 ;-)
Ce qui va poser un problème c'est le budget, il faudra le justifier sous peine de ne plus avoir autant la prochaine fois.
[^] # Re: blockchain
Posté par Kerro . Évalué à 0.
Si les terminaux de cartes bancaires sont certifiés, alors les cartes bancaires peuvent faire office de participant à la blockchain. Surtout depuis qu'elles intègrent un porte-monaie électronique (en admettant qu'il soit correctement réalisé, je n'en connais pas les détails et d'expérience je suppose que c'est à peu près naze).
[^] # Re: blockchain
Posté par Neo_13 . Évalué à 2.
Euh, la blockchain ne te garantit pas que la machine droppe aléatoirement une transaction sur 10.
Elle te garantit uniquement que si elle ne l'a pas fait, elle ne le fera pas plus tard.
Elle ne protège pas du bouton vert sur la caisse "passer cette transaction au noir parce que le mec paye en liquide".
[^] # Re: blockchain
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
La loi a changé, si un vendeur de machine est pris, il est solidaire des fraudes faites avec… Je ne suis pas sûr que cela en vaut la peine.
"La première sécurité est la liberté"
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.