J’ai lu depuis plusieurs mois, plusieurs articles sur la nouvelle loi qui entre en vigueur le 1er janvier 2018 sur les caisses antifraude. Ainsi que les éditeurs vont devoir fournir une attestation d’homologation pour leur logiciel.
Dans la newsletter de mon expert comptable de cette semaine, il y a un article similaire, mais avec une énorme différence. Cette fois-ci il ne s’agit plus simplement des caisses enregistreuses, mais des systèmes comptable et de gestion.
Sont concernées toutes les entreprises assujetties à la TVA qui utilisent des logiciels de #comptabilité ou de gestion ou des systèmes de caisse pour enregistrer les paiements de leurs clients
Retour en arrière
Il m’est revenu en mémoire un article de Philippe SCOFFONINET (Auteur, blogueur) et dirigeant d’OPEN DSI à Lyon.
Dans cet article il évoque la fin des logiciels libres comptable et gestion de caisse.
Enfin si, car si vous installez un logiciel libre et que le client bidouille ou fasse bidouiller le programme en question pour frauder et se fait pincer, vous êtes responsable aux yeux de la loi
J’ai aussi fait une recherche sur le forum de Dolibarr, et l’excitation est à son comble. Car bien sûr, et je comprends parfaitement cette loi peut tuer toutes les solutions libres de facturation.
Analysons
Du souci pour rien, pour reprendre les mots de Philippe, je pense que oui. Et voilà pourquoi :
Si je prends un logiciel propriétaire, Sage par exemple, qui va sans aucun doute obtenir l’homologation, la solution n’est pas forcement sécurisé.
Sage Ligne 100 existe en 2 versions, une version base propriétaire, et une version en base #SQL Serveur. Lorsque l’on utilise la version propriétaire, en voie de disparition, l’accès aux données de la base ne peut se faire qu’en lecture, et en écriture uniquement via des fonctions très précises.
Lorsque l’on utilise Sage 100 en version SQL Serveur, cette fois ci, si vous êtes administrateur SQL vous avez un accès complet à la base de données en lecture et écriture.
Ainsi il est par exemple parfaitement possible de décloturer une comptabilité Sage 100 via SQL, et ensuite de refaire la clôture (c’est formellement interdit, mais faisable en théorie). Cette opération est impossible en version basse propriétaire. Et très sincèrement je pense que c’est aussi possible avec les bons outils, car le basse propriétaire et SQL sont identiques. La principale différence entre les deux, c’est les performances du moteur SQL.
Idem pour Sage PE qui est en format Access, ou WaveSoft aussi en SQL, EBP qui est aussi en SQL. Mais aussi les éditeurs d’#ERP comme SAP, Microsoft, Divalto, Cegid, Oracle, etc. En fait-tous les éditeurs qui ont choisi des moteurs de base de données SQL sont sensibles à ce problème.
Comprendre le fonctionnement
Depuis la loi applicable au 1er janvier 2014 sur les logiciels de comptabilité, les éditeurs ont utilisé une parade relativement simple, et donc relativement simple à contourner si vous maitrisez le langage SQL.
Le principe est très simple, les données sont stockées dans une table, qui comporte un numéro automatique. Lorsque vous supprimez une ligne, la ligne n’est pas vraiment supprimée dans la table. L’enregistrement est marqué par ce que l’on appelle techniquement un Soft Delete. Lorsque vous interrogez votre logiciel, il n’affiche que les éléments n’ayant pas le Soft Delete activé.
Lorsque vous réalisez un export pour l’administration fiscale, tous les enregistrements sont listés, y compris les Soft Delete. L’administration n’a plu qu’a vérifié que tous les numéros se suivent, et de comparer les écritures Soft Delete avec celle qui les ont été remplacer.
En ayant quelques notions de SQL, il est facile de supprimer les Soft Delete et de relancer la numérotation des lignes.
Finalement pas que les logiciels libres
Je crois que tous les éditeurs vont avoir un gros problème à gérer, sauf si c’est simplement une histoire de taxe à faire payer aux éditeurs, et de refacturation au client final la mise à jour exceptionnellement payante (Sage PE mise à jour I7).
Car le problème est présent dans tous les logiciels de #gestion commerciale, ERP, Caisse et bien sûr comptable.
Les éditeurs pourraient par exemple imaginer de faire un calcul mathématique sur chaque ligne saisie, puis crypter celui-ci afin de garantir qu’une ligne n’a pas été modifiée hors du logiciel. Mais reste encore le problème de la suppression, car une ligne qui a disparu, a complètement disparu, sa signature unique aussi.
Mais cette solution n’est pas fiable non plus, car avec une année d’écriture comptable, il est possible de calculer la clé de cryptage sur plus de 10 000 lignes.
La solution
La seule solution c’est que les utilisateurs ne puissent pas avoir un accès administrateur à la base de données. Et pour moi le seul moyen pour que le système soit pratiquement incontournable, c’est que le système soit en SAAS.
Dans ce cas précis l’utilisateur, même administration de l’entreprise cliente n’a aucun accès, hors interface de saisie, à l’écriture des données dans la base.
Au 1er janvier 2018 tous vers le Cloud pour la comptabilité et la gestion !
Et si on va un petit peu plus loin
J’ai parlé pour l’instant des logiciels de gestion (facturation) et des ERP dans les entreprises. Mais pour les boutiques en ligne comment cela va-t-il se passer ?
Woocommerce, Magento, Prestashop vont-ils être certifiés ? Car il existe des entreprises dont c’est le seul outil de facturation.
Et pour reprendre le texte à la lettre, toutes les entreprises soumises à TVA. On parle des entreprises qui ont un système de facturation propriétaire : Amazon, Google, etc.
Pour conclure
Je pense que le législateur a été une fois encore mal conseillé par les éditeurs de logiciel propriétaire, et que malheureusement aucun n’a consulté des experts en base de données pour savoir réellement en quoi cette loi devient désuète.
Pour réponde à Philippe et aussi à la communauté Dolibarr, je pense qu’il doit exister une solution très simple pour avoir ce certificat, sinon tous les éditeurs ont beaucoup de travail a fournir pour rendre leur logiciel conforme à la loi et inaltérable par les experts SQL.
PS: J’espère que vous ferez lire cet article aux députés pour qu’il trouve un amendement.
Bonjour Cédric,
Merci pour l’article.
L’utilisation de la blockchaine est alors recommandé pour eviter de pouvoir supprimer des entrées comptable.
Avez eu plus d’information cepuis l’année derniere
La ceritfication se fait au pres des organismes comme Infocert , mais il est tout aussi possible de faire une auto-certification, à vos risques …
Bonjour,
Le BlockChain, la révolution en marche en terme d’authentification. Parfaitement d’accord avec votre analyse, mais pour l’instant, cela reste de la techno à venir.
Soyons honnête, même avec une certification, nous savons tous qu’il est quand même possible dans une base de données de modifier facilement l’information.
Je reste convaincu que c’est une loi utile, mais qui ne résout rien, car techniquement tout est possible pour l’instant.
Merci pour votre retour
Bonjour,
La solution existe pourtant pour les logiciels de caisse certifiés NF525 depuis le 01/01/2017.
Le principe de base du blockchain c’est de lier une liste d’information par signature cryptographique, chacune certifiant la validité de la précédente.
C’est exactement pareil pour les lignes comptables, que ce soit en SQL ou non. Chaque nouvelle ligne peut avoir une signature qui certifie à la fois les informations date/débit/crédit ainsi que la signature de la ligne précédente.
Ainsi, toute les lignes comptables peuvent être chaînées, et le suppression de n’importe quelle ligne casserait la signature de la suivante, et serait détectable assez simplement.
Et admettons que vous supprimé la derniére écriture, ou tout simplement vous n’écrivez rien ?
Une modif du code source suffit, évidement c’est plus complexe, de plus pour valider un paiement en ligne par CB, il faut le retour. Donc en ajoutant un simple .htaccess pour désactiver l’IP du serveur de temps en temps n’inscrira pas la facture, Il faut pas être un pro pour ajouter un .htaccess.
En somme, la seul solution est de restreindre l’accès aux E-boutique au seul développeur que ce soit en FTP et l’installation d’addons, puis que le manager certifie le serveur comme inaltérable.
Toutes autres solutions ou la société possédant l’e-boutique peu modifier les fichiers genre serveur autogéré par elle même est impossible à vérifié et donc à certifier.
Oui bien sur, donc une solution sur laquelle ni les administrateurs, ni les utilisateurs n’ont la main. Une solution SAAS par exemple.
Merci de votre analyse.