Quelques remarques pragmatiques :
- si ces "nous", "capables" de concevoir et produire des FPGAs et processeurs "compétitifs et libres" existaient, on aurait déjà depuis 20 ans ces produits sur le marché.
- si "vos" visions de la liberté étaient si importante pour les utilisateurs, les constructeurs actuels se plieraient à ces exigences d'ouverture depuis bien longtemps.
Bref, votre discours je l'entend depuis plus de 20 ans et ces 2 décennies ont démontré qu'il est basé sur du vent.
Si "vous", au sens des "nous allons", êtes capable de faire cela c'est que "vous" êtes capables de concevoir et fabriquer des processeurs ou FPGA en France qui sont "compétitifs" en terme de prix ou de vitesse…
Evidemment qu'entre utiliser un langage qui existe (C/C++/Basic/Java/Python/Cobol/…) et créer le fameux M (et son compilateur) parce que peut être que 20 ans plus tard certains de ces langages pourraient être moins utilisés, c'est très intelligent.
Pour rebondir sur la qualité de ce langage et ses qualité, les slides de présentation nous apprennent que :
positif(a) se traduit par Si a > 0 alors 1 sinon 0
Ce qui fait que le petit exemple :
si
V_IND_TRAIT > 0
et
positif(COD2FA + 0) + positif(RCMHAB + 0) > 1
alors erreur A226 ;
démontre au combien nous avons des stars de la programmation. Car le code :
si
V_IND_TRAIT > 0 et COD2FA> 0 et RCMHAB > 0
alors erreur A226 ;
est strictement équivalent en M.
Les questions à se poser sont aussi pourquoi en 2016, M n'a pas disparu… et pourquoi on se félicite de cela, quitte à défendre comme tu le fais ce Machin. As tu des amis dans ces milieux ou apprécies tu que tes impôts soient utilisés à maintenir ce genre de blague tout en se félicitant dans la presse de l'ouverture du code?
Mes remarques ne sont pas vindicatives, je ne suis pas non plus sur mon petit nuage du tout est merveilleux. Je passe peut être trop de temps à dealer avec toutes les aberrations informatique que nous pondent URSSAF, DGI et autres. Ces formats à colonne fixe, à transtypage inutiles, les formats où les caractères sont '7bits' + exceptions, les formats ou les lignes ne doivent pas dépasser 256 caractères : j'en ai ma claque.
Tu penses bien que l'XML ou JSON et l'UTF8 sont trop récents ou pas assez badass.
Seulement cela ne concerne pas de vieux trucs, mais la DSN qui rentre en application ce juillet, ou encore l'export FEC pondu il y a 1 an…
C'est tellement simple que tu vas nous expliquer la rationalité de la chose… un expert pour décoder ce test?
Je dois vraiment fatigué en ce moment, j'ai du mal à voir l’intérêt de traduire le M et Python plutôt que d'écrire des 'if' en Python en sacrifiant le 'si'.
En 1985, j'utilisais déjà un truc facile d'accès qui s'appelait le BASIC, alors vouloir m'expliquer qu'en 1996 on n'avait rien pour coder, c'est en avoir dans le pantalon.
Humm… parce que pour écrire ça : https://github.com/openfisca/calculette-impots-m-source-code/blob/master/src/chap-87.m
les langages qui existaient en 1996 : Java, C, C++, Python et j'en passe…
n'étaient pas assez adaptés et cela justifiait de créer un beau langage tout en français, son compilateur et 20 ans de maintenance… sans compter la formation des petits nouveaux.
J'aime bien ce côté "rien a foutre des standards" de nos institutions.
Vive les langages SAS et M, ouvrons nos esprits à ces langages, voyons!
Une réécriture en BF financée par nos impôts s'impose…
Evidemment nous certifierons le logiciel, les modifications techniques ne sont pas énormes.
Nous communiquerons dessus plus tard, car les échéances sont lointaines et avons bien d'autres choses à développer pour l'instant.
Super logiciel, bravo. NanoKontrol2 opérationnel en moins de 2 minutes!
Ni connaissant rien en DJ'ing, je peux juste dire que l'ensemble est vraiment bien fini, intuitif et amusant à prendre en main.
Qu'est ce que c'est que cette interface graphique?
Elle piétine les standards dans les grandes largeurs!
Difficile de trouver icônes plus moche,
les layouts sont plus qu'étranges,
et le look and feel natif même pas activé ( Tips: UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName()); )
Merci d'utiliser des SwingWorker pour ne pas bloquer la thread principale de Swing.
Oui, exact. Ajout et suppression doivent être interdit par le logiciel.
Mon propos est justement lié au logiciel, on ne peut à mon sens n'imposer à l'éditeur d'un logiciel que des choses relatives au logiciel, pas relatives à l'utilisateur.
Petit parallèle avec les armes pour changer d'optique:
Est ce que l'on met en prison les fabricants de couteaux quand certains font de la boucherie humaine?
Non, évidement.
Dans la même logique, on ne doit pas impliquer l'éditeur à l'utilisation frauduleuse de son logiciel.
Et tout comme il est interdit de créer des bombes atomiques, un éditeur de logiciel doit être lourdement sanctionné s'il intègre des fonctionnalités de fraude.
Bon allez… il est temps pour moi d’arrêter de commenter à tout va, c'est bien sympathique d'échanger ici, mais ça n'aura aucun effet sur le vote du projet de loi, ni sur la fraude.
Ce ne fait que du temps en moins à consacrer à des sujets plus constructifs, passionnants et loin de la bêtises législative qui au fil du temps déresponsabilise la majorité, démoralise les créateurs et grignote les libertés.
Oui.
Le seul "hic" vient du fait que la première transaction n'a pas de transaction précédente ;)
Plus généralement, pour modifier" ni vu ni connu" la n-eme transaction, il suffit d’effacer toutes les suivantes au passage et de les recréer.
Le problème n'est pas tant au niveau des coût pour "nous" les éditeurs, mais surtout pour les entreprises en général… Le coût de la certification n'est rien par rapport aux centaines de millions d'euros que va coûter en temps/prestations/licences, une mesure inefficace et facilement contournable (cf mes autres posts).
Pour ceux qui n'aurez pas vu passé l'info, au sujet de la norme NF 525, rien que l'obtention des règles de certification est payant (500€)… mais peut être doit on déjà se réjouir que la consultation du projet de loi est gratuite. J'ai personnellement du mal à me faire à cette société qui pense régler les problèmes de fond par des taxes, des normes, des interdictions…
L'administration détruit déjà assez d'entreprises comme cela, si l'on peut éviter de plomber encore un peu plus l'économie, faisons le. Je reste persuadé, que l'état ne récupérera que des miettes de ce qu'il pense récupérer sur les ventes "masquées", tout comme Hadopi a freiné le piratage.
Il y a d'autres moyens de faire "ce que vous pensez que l'administration fiscale veut", si tenté que votre interprétation soit celle des auteurs de la chose.
Pour ce qui est du module autonome, la loi n'en parle pas, elle parle de logiciel (donc l'ensemble).
Si c'était le cas, la loi ressemblerait plutôt à cela:
"Tout logiciel de gestion, de comptabilité, de caisse ou d'encaissement a l'obligation légale d'empêcher toute suppression d'écritures comptable par l'utilisateur. L'administration fiscale s'autorise en cas de doute avéré de procéder à un audit du code source fournit par l'éditeur."
Le raisonnement est valable pour une voiture, pas pour un logiciel de gestion / ERP.
On impose pas à une voiture de 2010 de respecter les normes de 2015.
La législation fiscale évolue sans cesse, récemment il a fallut ajouter l'export FEC, pour bientôt la DSN…
En gros, pour avoir un logiciel dans les clous, il faut le mettre à jour chaque année.
Dans un ERP, vu que tout est unifié et adapté à l'entreprise, il y a quasiment un logiciel par entreprise.
Bref, pour nous (OpenConcerto), il va falloir "faire certifier" ou "auto certifier" de nombreuses versions, même si la partie qui traite les encaissements est commune. Il nous faudra aussi mettre en place des systèmes pour garantir que le logiciel installé correspond au code source associé.
Cela prendra du temps, comprendre de l'argent, l'argent provenant des clients, mécaniquement ça va coûter aux utilisateurs.
Juste en temps, mettre à jour 3 millions de logiciels (dans l’hypothèse ou les 3 millions d'entreprises française vont utiliser un logiciel de gestion à jour…), cela prendre 3 millions d'heures de travail inutile MINIMUM (soit 342 années de vie).
De plus, l’efficacité contre la fraude sera nulle.
Qui voudra frauder, trouvera comment. Il ne faut pas être très calé pour comprendre qu'utiliser un autre logiciel en parallèle suffira ou encore, tout simplement, ne pas comptabiliser ce que l'on ne veut pas déclarer…
Niveau fraude côté éditeur, les cas avérés sont des logiciels propriétaires. Avec un logiciel libre, c'est plus difficile de cacher une fonctionnalité "de bricolage" car le code est accessible.
Obliger tout éditeur à donner accès au code source de son logiciel pour contrôle, cela serait une loi plus pertinente.
```
Depuis quand il faut des accords pour générer des fichiers SEPA ????
Pour l'interface avec les banques, il y a EBICS, pas besoin d'accord non plus… le client paye son accès.
3 millions d'entreprises…
Valorisez le temps à passer, les licences, les prestations… on dépasse le milliard d'euros pour un résultat sur la fraude qui sera à la hauteur d'Hadopi ;)
Avec OpenConcerto, on a plus de 200 000 entrepreneurs qui seraient potentiellement ravis d'envoyer un petit email ou appeler nos chers responsables…
Il manque un point important, c'est l'impact économique de cette loi sur l'ensemble des entreprises, logiciels libres ou pas.
En effet, tout le monde devra passer à des nouvelles versions de logiciels "inaltérables", c'est-à-dire passer à la caisse d'une façon ou d'une autre. Même avec des logiciels libres, cela ne se fera pas à coût zéro (temps, prestations diverses…).
Les amateurs d'Excel ou Libre/OpenOffice devront apprendre à s'en séparer.
Il serait de bon ton de partager numéro de téléphone ou email de ces chers "responsables" à la tête du projet.
Il y a des centaines d'entrepreneurs qui seraient heureux de leur envoyer leur avis et quelques éditeurs comme nous (OpenConcerto) de leur expliquer l'inefficacité de leur projet et l'impact sur nous et les entreprises en général.
La valeur ajoutée tourne autours du travail des personnes qui ont réalisé ce système prêt à l'emploi.
Cela devient usant de voir le manque de respect de certains vis à vis du travail fait dans le milieu du logiciel libre.
J'aime beaucoup la façon que tu as de prêter aux autres des propos qu'ils n'ont pas, le tout pour dénigrer des stéréotypes.
Où as tu vu que je revendique que personne ne veut m'écouter?
Est ce que ce projet de loi s'attaque aux causes? Non.
Est ce que ce projet de loi va empêcher la fraude? Non.
Est ce qu'il faut lutter contre la fraude? Oui.
Tu considères que ce projet de loi est une bonne chose et qu'il va remettre dans le droit de chemin les fraudeurs, très bien. Je respecte ce point de vu, même si à part dire qu'il ne faut pas se poser de questions, tu refuses toute discussion argumentée.
SI l'on considère qu'un fraudeur trouvera toujours un moyen de frauder, je ne sais pas comment on peut conclure que ce projet loi va être utile (hormis imposer des coûts supplémentaires aux honnêtes gens et balancer des amendes aux non fraudeurs qui n'auraient pas acquis un logiciel certifié).
Pour nos voitures, on y vient doucement : traceurs, système eCall, firmware des composants cryptés… on parle même de pouvoir arrêter les véhicules à distance…
Je ne peux que souhaiter que tu ais raison et que tout cela se limite par une liste de fournisseurs certifiés. Certification non pas basée sur leur "cotisations" mais basée sur la réalité du fonctionnement.
C'est un début de solution mais techniquement, il reste des difficultés :
- la base de données : comment empêcher toute manipulation de la base par un logiciel tier?
La crypter? Dans ce cas, le logiciel certifié contient la clef. Avec un peu de persévérance, on la récupère et le tour est joué.
- la couche graphique : si la couche graphique est modifiée pour ne pas se servir de l'API certifiée, tout est falsifiable par détournement.
Certifier la couche graphique? Dans ce cas, il y a nécessité de re-certifier le tout à chaque modification, optimisation, correction de bugs…
Bref, il n'y a aucune incompatibilité dedans, si ce n'est des fantasmes. Surtout que la problématique existe depuis longtemps, pourquoi se focaliser sur ce projet de loi en particulier ?
Il n'y a rien de particulier à cette loi, elle est dans la logique actuelle qui est de ne jamais adresser aux causes mais utiliser tout ce que l'on peut pour minimiser les conséquences.
Dans ce cas de figure, il ne s'agit pas de pollution, de sécurité, de compatibilité,… sujets sur lesquels personne ne pourra contester l’intérêt des réglementations.
Il s'agit ici de contraintes, de coûts supplémentaires et d'amendes qui vont tomber sur ceux qui ne fraudent pas mais qui vont être en défaut de conformité.
Les fraudeurs trouveront toujours de quoi frauder, les seuls perdants de l'histoire seront les non-fraudeurs.
Quand tout le monde aura fait le constat que la certification n'aura rien changé, on va aller vers l'utilisation de système d'exploitation certifié? De puces DRM obligatoires? De systèmes de télésurveillances dans chaque entreprise? Faut il un permis pour utiliser un compilateur?
Bref, à trop croire à ce genre de solution, on se retrouve à financer des Hadopi, des systèmes de surveillance globaux et légaux, mais surtout un système législatif de plus en plus complexe et coûteux.
[^] # Re: La "libération" de ce FPGA est une excellente chose
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Icestudio 0.2, du schéma au verilog. Évalué à -1.
Quelques remarques pragmatiques :
- si ces "nous", "capables" de concevoir et produire des FPGAs et processeurs "compétitifs et libres" existaient, on aurait déjà depuis 20 ans ces produits sur le marché.
- si "vos" visions de la liberté étaient si importante pour les utilisateurs, les constructeurs actuels se plieraient à ces exigences d'ouverture depuis bien longtemps.
Bref, votre discours je l'entend depuis plus de 20 ans et ces 2 décennies ont démontré qu'il est basé sur du vent.
[^] # Re: La "libération" de ce FPGA est une excellente chose
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Icestudio 0.2, du schéma au verilog. Évalué à 0.
Si "vous", au sens des "nous allons", êtes capable de faire cela c'est que "vous" êtes capables de concevoir et fabriquer des processeurs ou FPGA en France qui sont "compétitifs" en terme de prix ou de vitesse…
Alors pourquoi s’embêter à "libérer"?
[^] # Re: osm map via BitTorrent
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Une grosse tuile pour GNOME Maps. Évalué à 4.
Ou encore télécharger la carte de France sur son PC (3 Go).
[^] # Re: Sur M
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche L'Insee et la Drees ouvrent le code source du modèle Ines. Évalué à 1.
Evidemment qu'entre utiliser un langage qui existe (C/C++/Basic/Java/Python/Cobol/…) et créer le fameux M (et son compilateur) parce que peut être que 20 ans plus tard certains de ces langages pourraient être moins utilisés, c'est très intelligent.
Pour rebondir sur la qualité de ce langage et ses qualité, les slides de présentation nous apprennent que :
positif(a) se traduit par Si a > 0 alors 1 sinon 0
Ce qui fait que le petit exemple :
démontre au combien nous avons des stars de la programmation. Car le code :
est strictement équivalent en M.
Les questions à se poser sont aussi pourquoi en 2016, M n'a pas disparu… et pourquoi on se félicite de cela, quitte à défendre comme tu le fais ce Machin. As tu des amis dans ces milieux ou apprécies tu que tes impôts soient utilisés à maintenir ce genre de blague tout en se félicitant dans la presse de l'ouverture du code?
Mes remarques ne sont pas vindicatives, je ne suis pas non plus sur mon petit nuage du tout est merveilleux. Je passe peut être trop de temps à dealer avec toutes les aberrations informatique que nous pondent URSSAF, DGI et autres. Ces formats à colonne fixe, à transtypage inutiles, les formats où les caractères sont '7bits' + exceptions, les formats ou les lignes ne doivent pas dépasser 256 caractères : j'en ai ma claque.
Tu penses bien que l'XML ou JSON et l'UTF8 sont trop récents ou pas assez badass.
Seulement cela ne concerne pas de vieux trucs, mais la DSN qui rentre en application ce juillet, ou encore l'export FEC pondu il y a 1 an…
Il y de quoi alimenter http://thedailywtf.com/ pendant des années.
[^] # Re: Sur M
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche L'Insee et la Drees ouvrent le code source du modèle Ines. Évalué à -2.
Evidemment!
positif(COD2FA + 0) + positif(RCMHAB + 0) > 1
C'est tellement simple que tu vas nous expliquer la rationalité de la chose… un expert pour décoder ce test?
Je dois vraiment fatigué en ce moment, j'ai du mal à voir l’intérêt de traduire le M et Python plutôt que d'écrire des 'if' en Python en sacrifiant le 'si'.
En 1985, j'utilisais déjà un truc facile d'accès qui s'appelait le BASIC, alors vouloir m'expliquer qu'en 1996 on n'avait rien pour coder, c'est en avoir dans le pantalon.
[^] # Re: Yes
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche L'Insee et la Drees ouvrent le code source du modèle Ines. Évalué à 2.
Humm… parce que pour écrire ça : https://github.com/openfisca/calculette-impots-m-source-code/blob/master/src/chap-87.m
les langages qui existaient en 1996 : Java, C, C++, Python et j'en passe…
n'étaient pas assez adaptés et cela justifiait de créer un beau langage tout en français, son compilateur et 20 ans de maintenance… sans compter la formation des petits nouveaux.
Pour les lecteurs pressés, voici un extrait de code M écrit avec nos impôts (https://github.com/openfisca/calculette-impots-m-source-code/blob/master/src/coc2.m , fin de fichier) :
On applaudira chaudement le style.
# Yes
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche L'Insee et la Drees ouvrent le code source du modèle Ines. Évalué à -2.
J'aime bien ce côté "rien a foutre des standards" de nos institutions.
Vive les langages SAS et M, ouvrons nos esprits à ces langages, voyons!
Une réécriture en BF financée par nos impôts s'impose…
Je vous laisse admirer le beau HTML 'Microsoft Word 12' de cette page https://ines-libre.adullact.net/
Misérable.
[^] # Re: Loi finances 2016
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche L’ERP OpenConcerto passe en version 1.4. Évalué à 2.
Evidemment nous certifierons le logiciel, les modifications techniques ne sont pas énormes.
Nous communiquerons dessus plus tard, car les échéances sont lointaines et avons bien d'autres choses à développer pour l'instant.
# Bravo
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Sortie de Mixxx 2.0. Évalué à 3.
Super logiciel, bravo. NanoKontrol2 opérationnel en moins de 2 minutes!
Ni connaissant rien en DJ'ing, je peux juste dire que l'ensemble est vraiment bien fini, intuitif et amusant à prendre en main.
[^] # Re: Compte-rendu analytique de la séance d'hier, 16 décembre
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Projet de loi de finances FR 2016 : interdiction des logiciels libres de comptabilité et de caisse. Évalué à 1.
Bonjour,
Nous serions interessé de faire sa lecture.
Par email à ilm-informatique.fr sur l'email de "contact@…"
Merci d'avance.
# Peut mieux faire.
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Algem, logiciel de gestion d'activités culturelles. Évalué à 5.
Au secours!
Qu'est ce que c'est que cette interface graphique?
Elle piétine les standards dans les grandes largeurs!
Difficile de trouver icônes plus moche,
les layouts sont plus qu'étranges,
et le look and feel natif même pas activé ( Tips: UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName()); )
Merci d'utiliser des SwingWorker pour ne pas bloquer la thread principale de Swing.
[^] # Re: Dura lex, sed lex ou le problème des logiciels à plusieurs utilisateurs
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Projet de loi de finances FR 2016 : interdiction des logiciels libres de comptabilité et de caisse. Évalué à 3.
Oui, exact. Ajout et suppression doivent être interdit par le logiciel.
Mon propos est justement lié au logiciel, on ne peut à mon sens n'imposer à l'éditeur d'un logiciel que des choses relatives au logiciel, pas relatives à l'utilisateur.
Petit parallèle avec les armes pour changer d'optique:
Est ce que l'on met en prison les fabricants de couteaux quand certains font de la boucherie humaine?
Non, évidement.
Dans la même logique, on ne doit pas impliquer l'éditeur à l'utilisation frauduleuse de son logiciel.
Et tout comme il est interdit de créer des bombes atomiques, un éditeur de logiciel doit être lourdement sanctionné s'il intègre des fonctionnalités de fraude.
Bon allez… il est temps pour moi d’arrêter de commenter à tout va, c'est bien sympathique d'échanger ici, mais ça n'aura aucun effet sur le vote du projet de loi, ni sur la fraude.
Ce ne fait que du temps en moins à consacrer à des sujets plus constructifs, passionnants et loin de la bêtises législative qui au fil du temps déresponsabilise la majorité, démoralise les créateurs et grignote les libertés.
[^] # Re: inaltérabilité
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Projet de loi de finances FR 2016 : interdiction des logiciels libres de comptabilité et de caisse. Évalué à 3.
Oui.
Le seul "hic" vient du fait que la première transaction n'a pas de transaction précédente ;)
Plus généralement, pour modifier" ni vu ni connu" la n-eme transaction, il suffit d’effacer toutes les suivantes au passage et de les recréer.
[^] # Re: Je ne vois pas bien l'interdiction du logiciel libre
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Projet de loi de finances FR 2016 : interdiction des logiciels libres de comptabilité et de caisse. Évalué à 7.
Bonjour,
Le problème n'est pas tant au niveau des coût pour "nous" les éditeurs, mais surtout pour les entreprises en général… Le coût de la certification n'est rien par rapport aux centaines de millions d'euros que va coûter en temps/prestations/licences, une mesure inefficace et facilement contournable (cf mes autres posts).
Pour ceux qui n'aurez pas vu passé l'info, au sujet de la norme NF 525, rien que l'obtention des règles de certification est payant (500€)… mais peut être doit on déjà se réjouir que la consultation du projet de loi est gratuite. J'ai personnellement du mal à me faire à cette société qui pense régler les problèmes de fond par des taxes, des normes, des interdictions…
L'administration détruit déjà assez d'entreprises comme cela, si l'on peut éviter de plomber encore un peu plus l'économie, faisons le. Je reste persuadé, que l'état ne récupérera que des miettes de ce qu'il pense récupérer sur les ventes "masquées", tout comme Hadopi a freiné le piratage.
Il y a d'autres moyens de faire "ce que vous pensez que l'administration fiscale veut", si tenté que votre interprétation soit celle des auteurs de la chose.
Pour ce qui est du module autonome, la loi n'en parle pas, elle parle de logiciel (donc l'ensemble).
[^] # Re: Dura lex, sed lex ou le problème des logiciels à plusieurs utilisateurs
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Projet de loi de finances FR 2016 : interdiction des logiciels libres de comptabilité et de caisse. Évalué à 2.
Si c'était le cas, la loi ressemblerait plutôt à cela:
"Tout logiciel de gestion, de comptabilité, de caisse ou d'encaissement a l'obligation légale d'empêcher toute suppression d'écritures comptable par l'utilisateur. L'administration fiscale s'autorise en cas de doute avéré de procéder à un audit du code source fournit par l'éditeur."
[^] # Re: Je ne vois pas bien l'interdiction du logiciel libre
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Projet de loi de finances FR 2016 : interdiction des logiciels libres de comptabilité et de caisse. Évalué à 5.
Bonjour,
Le raisonnement est valable pour une voiture, pas pour un logiciel de gestion / ERP.
On impose pas à une voiture de 2010 de respecter les normes de 2015.
La législation fiscale évolue sans cesse, récemment il a fallut ajouter l'export FEC, pour bientôt la DSN…
En gros, pour avoir un logiciel dans les clous, il faut le mettre à jour chaque année.
Dans un ERP, vu que tout est unifié et adapté à l'entreprise, il y a quasiment un logiciel par entreprise.
Bref, pour nous (OpenConcerto), il va falloir "faire certifier" ou "auto certifier" de nombreuses versions, même si la partie qui traite les encaissements est commune. Il nous faudra aussi mettre en place des systèmes pour garantir que le logiciel installé correspond au code source associé.
Cela prendra du temps, comprendre de l'argent, l'argent provenant des clients, mécaniquement ça va coûter aux utilisateurs.
Juste en temps, mettre à jour 3 millions de logiciels (dans l’hypothèse ou les 3 millions d'entreprises française vont utiliser un logiciel de gestion à jour…), cela prendre 3 millions d'heures de travail inutile MINIMUM (soit 342 années de vie).
De plus, l’efficacité contre la fraude sera nulle.
Qui voudra frauder, trouvera comment. Il ne faut pas être très calé pour comprendre qu'utiliser un autre logiciel en parallèle suffira ou encore, tout simplement, ne pas comptabiliser ce que l'on ne veut pas déclarer…
Niveau fraude côté éditeur, les cas avérés sont des logiciels propriétaires. Avec un logiciel libre, c'est plus difficile de cacher une fonctionnalité "de bricolage" car le code est accessible.
Obliger tout éditeur à donner accès au code source de son logiciel pour contrôle, cela serait une loi plus pertinente.
```
[^] # Re: Il faut relativiser
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Projet de loi de finances FR 2016 : interdiction des logiciels libres de comptabilité et de caisse. Évalué à 6.
Depuis quand il faut des accords pour générer des fichiers SEPA ????
Pour l'interface avec les banques, il y a EBICS, pas besoin d'accord non plus… le client paye son accès.
La preuve en image : OpenConcerto.
[^] # Re: Liberté, Égalité, Fraternité
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Projet de loi de finances FR 2016 : interdiction des logiciels libres de comptabilité et de caisse. Évalué à 9.
3 millions d'entreprises…
Valorisez le temps à passer, les licences, les prestations… on dépasse le milliard d'euros pour un résultat sur la fraude qui sera à la hauteur d'Hadopi ;)
Avec OpenConcerto, on a plus de 200 000 entrepreneurs qui seraient potentiellement ravis d'envoyer un petit email ou appeler nos chers responsables…
# Liberté, Égalité, Fraternité
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Projet de loi de finances FR 2016 : interdiction des logiciels libres de comptabilité et de caisse. Évalué à 10.
Merci pour ce récapitulatif.
Il manque un point important, c'est l'impact économique de cette loi sur l'ensemble des entreprises, logiciels libres ou pas.
En effet, tout le monde devra passer à des nouvelles versions de logiciels "inaltérables", c'est-à-dire passer à la caisse d'une façon ou d'une autre. Même avec des logiciels libres, cela ne se fera pas à coût zéro (temps, prestations diverses…).
Les amateurs d'Excel ou Libre/OpenOffice devront apprendre à s'en séparer.
Il serait de bon ton de partager numéro de téléphone ou email de ces chers "responsables" à la tête du projet.
Il y a des centaines d'entrepreneurs qui seraient heureux de leur envoyer leur avis et quelques éditeurs comme nous (OpenConcerto) de leur expliquer l'inefficacité de leur projet et l'impact sur nous et les entreprises en général.
[^] # Re: valeur ajoutée ?
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Linutop OS XS disponible pour tous les Raspberry PI (Zéro, A, A+, B, B+ et 2) :. Évalué à -1.
Et face à une orange, c'est cher?
La valeur ajoutée tourne autours du travail des personnes qui ont réalisé ce système prêt à l'emploi.
Cela devient usant de voir le manque de respect de certains vis à vis du travail fait dans le milieu du logiciel libre.
# Design orthogonal
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Kakoune, un éditeur de texte qui a du caractère. Évalué à 9.
Je ne sais pas vous, mais moi que je lis du "design orthogonal", je me pose des questions sur le taux de pipoware associé.
[^] # Re: Modification de législation française et logiciel libre de caisse/compta
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Présentation Odoo à Paris, le 6 octobre 2015. Évalué à 1.
J'aime beaucoup la façon que tu as de prêter aux autres des propos qu'ils n'ont pas, le tout pour dénigrer des stéréotypes.
Où as tu vu que je revendique que personne ne veut m'écouter?
Est ce que ce projet de loi s'attaque aux causes? Non.
Est ce que ce projet de loi va empêcher la fraude? Non.
Est ce qu'il faut lutter contre la fraude? Oui.
Tu considères que ce projet de loi est une bonne chose et qu'il va remettre dans le droit de chemin les fraudeurs, très bien. Je respecte ce point de vu, même si à part dire qu'il ne faut pas se poser de questions, tu refuses toute discussion argumentée.
Bonne soirée.
[^] # Re: Modification de législation française et logiciel libre de caisse/compta
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Présentation Odoo à Paris, le 6 octobre 2015. Évalué à 0.
SI l'on considère qu'un fraudeur trouvera toujours un moyen de frauder, je ne sais pas comment on peut conclure que ce projet loi va être utile (hormis imposer des coûts supplémentaires aux honnêtes gens et balancer des amendes aux non fraudeurs qui n'auraient pas acquis un logiciel certifié).
Pour nos voitures, on y vient doucement : traceurs, système eCall, firmware des composants cryptés… on parle même de pouvoir arrêter les véhicules à distance…
Je ne peux que souhaiter que tu ais raison et que tout cela se limite par une liste de fournisseurs certifiés. Certification non pas basée sur leur "cotisations" mais basée sur la réalité du fonctionnement.
[^] # Re: limiter la casse
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Présentation Odoo à Paris, le 6 octobre 2015. Évalué à 1.
C'est un début de solution mais techniquement, il reste des difficultés :
- la base de données : comment empêcher toute manipulation de la base par un logiciel tier?
La crypter? Dans ce cas, le logiciel certifié contient la clef. Avec un peu de persévérance, on la récupère et le tour est joué.
- la couche graphique : si la couche graphique est modifiée pour ne pas se servir de l'API certifiée, tout est falsifiable par détournement.
Certifier la couche graphique? Dans ce cas, il y a nécessité de re-certifier le tout à chaque modification, optimisation, correction de bugs…
[^] # Re: Modification de législation française et logiciel libre de caisse/compta
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Présentation Odoo à Paris, le 6 octobre 2015. Évalué à 2. Dernière modification le 07 octobre 2015 à 14:34.
Il n'y a rien de particulier à cette loi, elle est dans la logique actuelle qui est de ne jamais adresser aux causes mais utiliser tout ce que l'on peut pour minimiser les conséquences.
Dans ce cas de figure, il ne s'agit pas de pollution, de sécurité, de compatibilité,… sujets sur lesquels personne ne pourra contester l’intérêt des réglementations.
Il s'agit ici de contraintes, de coûts supplémentaires et d'amendes qui vont tomber sur ceux qui ne fraudent pas mais qui vont être en défaut de conformité.
Les fraudeurs trouveront toujours de quoi frauder, les seuls perdants de l'histoire seront les non-fraudeurs.
Quand tout le monde aura fait le constat que la certification n'aura rien changé, on va aller vers l'utilisation de système d'exploitation certifié? De puces DRM obligatoires? De systèmes de télésurveillances dans chaque entreprise? Faut il un permis pour utiliser un compilateur?
Bref, à trop croire à ce genre de solution, on se retrouve à financer des Hadopi, des systèmes de surveillance globaux et légaux, mais surtout un système législatif de plus en plus complexe et coûteux.