Obligation d'utiliser des logiciels de Gestion certifiés à partir de 2018

Bonjour,

Je travaille aujourd’hui dans un cabinet comptable, et j’installe chez mes clients des logiciels de gestion commerciale et comptabilité développés sous 4D.

L’article de loi concerné est le suivant : http://bofip.impots.gouv.fr/bofip/10691-PGP.html?identifiant=BOI-TVA-DECLA-30-10-30-20160803

Je souhaiterais pouvoir auto-certifier nos logiciels car le coût de la certification par INFOCERT est bien trop important vu le volume de logiciels déployés chez nos clients (environ 200)

J’utilise 4D depuis des années, mais je suis loin de maitriser toutes les fonctionnalités un peu complexes.

Quelqu’un d’autre est-il concerné par cette loi sur ses développements ?

4D, de base, permet-il de répondre aux nouvelles exigences de la loi ou faut-il d’autres outils ?

Si oui, est-il envisageable d’apporter les modifications sur mes logiciels par moi même sans trop de prise de tête ?

La notion de “permissivité” et “inaltérabilité” concerne t-elle l’utilisateur final ou/et également le concepteur ?

Merci pour vos réponses …

J’ai parcouru l’article de loi et c’est une vraie usine à gaz. Je ne vois pas comment cela peut tenir la route, en particulier la mention faite sur les mises à jour d’un produit et ses différentes versions majeures, mineures, etc.
Si l’éditeur doit refaire certifier son logiciel à chaque révision du code (comme cela devrait être le cas), on n’a pas fini…Et ce sont les organismes de certifications qui vont avoir du boulot à vie pour contrôler tout cela !
Je ne vois même pas comment ces organismes pourront donner une certification cela voudrait dire qu’ils connaissent et ont du personnel formé pour tous les différents langages de programmation, etc.

Si ça finit pas sur une attestation sur l’honneur que votre logiciel ne contient pas de code permettant de frauder…:roll:

4D ne peut rien pour vous, puisqu’il s’agit de certifier les différentes fonctionnalités de votre logiciel…

On va finir par faire supprimer toute gestion de règlement et supprimer l’option de suppression/modification de fiche… :twisted:

Non, mon but n’est justement pas de faire certifier mes logiciels par une société spécialisée (INFOCERT pour ne pas la citer puisqu’à ma connaissance, il n’existe qu’elle … :-?) mais de nous auto-certifier en étant bien sûrs que les logiciels répondent aux éxigences du BOI…

J’imagine que le fichier de données (le 4DD) peut-être bidouillé par un autre outil que 4D, et qu’on pourrait imaginer qu’un petit malin pourrait trouver le moyen de supprimer des données de la base … Non ?

:?: Personne n’est concerné ? Je suis inquiet là car je ne sais vraiment pas par où commencer …

Tous les logiciels de Caisse, Compta et gestion commerciale sont visés par ce texte de loi, donc j’imagine que vous êtes plusieurs à être concernés … non ? :-?

: Sebastien BERNARD

Non, mon but n’est justement pas de faire certifier mes logiciels par
une société spécialisée (INFOCERT pour ne pas la citer puisqu’à ma
connaissance, il n’existe qu’elle … :-?) mais de nous
auto-certifier en étant bien sûrs que les logiciels répondent aux
éxigences du BOI…
Et en quoi consite exactement l’auto-certification :?: :roll:

: Sebastien BERNARD

J’imagine que le fichier de données (le 4DD) peut-être bidouillé par
un autre outil que 4D, et qu’on pourrait imaginer qu’un petit malin
pourrait trouver le moyen de supprimer des données de la base … Non ?
Supprimer (ou plus simplement modifier). Très sincèrement celui qui veut modifier un fichier trouvera toujours un moyen, à moins d’encoder et de crypter tout le fichier de donnée…

: Sebastien BERNARD

:?: Personne n’est concerné ? Je suis inquiet là car je ne sais
vraiment pas par où commencer …

Tous les logiciels de Caisse, Compta et gestion commerciale sont
visés par ce texte de loi, donc j’imagine que vous êtes plusieurs à
être concernés … non ? :-?

Cette loi concerne énormément de monde : développeurs, éditeurs, entreprises utilisatrices et bien sûr pas que sur 4D. Étonnamment on en entend peu parler et je te remercie d’avoir lancé ce fil.

La plupart de mes clients ne semble pas plus affolée que cela, ou met cela sous le tapis, or il me semble que c’est un sujet majeur pour 2017.

Les premiers concernés sont bien sûr les logiciels de gestion de caisse, secteur dans lequel la fraude existe.

Les “petits” (pas d’offense !) développeurs de compta (visiblement il en reste, tu en es la preuve) sont aussi en plein de dedans.

Quant aux développeurs de logiciels de gestion, je me demande s’il n’y a pas 2 catégories :

  • les applis qui gèrent les factures mais pas les règlements
  • celles qui gèrent toute la facturation y compris les règlements et exportent ensuite vers une compta standard type Sage

En effet, comme dans tout texte de loi, chaque virgule et chaque mot compte, et il se pourrait bien que l’alinéa I.B.1.80 dédouane la première catégorie :

Le logiciel de comptabilité ou de gestion ou le système de caisse doit enregistrer toutes les données d’origine relatives aux règlements. Il doit conserver ces données d’origine enregistrées et les rendre inaltérables.

Mais bien sûr ailleurs dans le texte c’est plus flou… :roll:

Si quelqu’un a une lecture à partager de cet alinéa ça m’intéresse… Une facturation ne gérant pas les règlements est-elle concernée ?

Concernant la certification elle-même, il s’agit tout simplement d’une attestation à remplir par l’éditeur. Il n’est bien sûr pas recommandé de l’établir à la légère. Pour moi la vraie difficulté n’est pas vraiment technique (je pense que l’outil 4D a toutes les cordes à son arc pour répondre aux nouvelles contraintes), elle est surtout commerciale et juridique : il s’agit en l’occurrence de convaincre chacun des clients concernés de la nécessité d’investir dans une mise à jour de leur programme d’ici 2018 (donc en se décidant avant décembre si possible…).

Mais beaucoup sont ou seront réticents : ça leur rappelle un peu le branle-bas de l’an 2000. Certains pensent qu’en période d’élections il est urgent d’attendre, que le prochain gouvernement pourrait purement et simplement abroger cette loi (perso j’en doute très fort).

Si tous mes clients disent OK, j’aurai probablement un problème de planning (plutôt un bon problème !) mais s’ils disent non, je fais quoi légalement parlant ? Je leur demande une décharge mentionnant qu’ils sont conscients que leur software de gestion n’est pas conforme ? Je leur interdis de l’utiliser ? Waouh c’est chaud !

Mon logiciel de gestion gére les règlements simplement pour gérer les
relances (reste dû de la facture) clients/fournisseurs SANS les
transférer en comptabilité. Suis-je concerné par cette loi ?

: Jean-Michel BIRAGHI

Je pense que l’outil 4D a toutes les cordes à son arc pour répondre
aux nouvelles contraintes
Comment tu fais actuellement pour figer ton fichier de donnée avec un checksum de contrôle ? si 4D décide lors d’une mise à jour (ou autre) de rajouter des elements ou changer le format de son fichier de donnée, ton checksum sera faux…

: Manuel PIQUET

Mon logiciel de gestion gére les règlements simplement pour gérer les
relances (reste dû de la facture) clients/fournisseurs SANS les
transférer en comptabilité. Suis-je concerné par cette loi ?

Si les règlements originaux sont saisis dans la compta, ton système de gestion des relances n’est finalement qu’un alias du point de vue des règlements et la certification de ta compta sera celle qui comptera. (Attention ! Hein ! Je ne suis ni juriste ni fiscaliste, mon avis vaut ce qu’il vaut)

Ca te ferait tomber dans le cas des gestions de facturation sans gestion des règlements, et là c’est moi qui ne suis plus très sûr : est-on concerné ou pas par la loi dans ce cas ? :roll:

: Manuel PIQUET

Comment tu fais actuellement pour figer ton fichier de donnée avec un
checksum de contrôle ? si 4D décide lors d’une mise à jour (ou autre)
de rajouter des elements ou changer le format de son fichier de
donnée, ton checksum sera faux…

Je ne vois pas l’intérêt de figer le fichier de données car il faudrait le faire à chaque changement d’une donnée concernée !

Encore une fois je ne pense pas que l’enjeu soit technique : il n’est pas difficile de rendre une table (ou certain de ses champs) non modifiable et de construire une interface autour pour l’alimenter sans aucune altération des données stockées, même en mode administration. Ca peut aussi passer par une utilisation systématique en compilé pour garantir la non altération de ce réglage… Bref il y a sûrement plein de façons d’être conformes et délivrer un certificat en bonne et due forme…

: Jean-Michel BIRAGHI

Je ne vois pas l’intérêt de figer le fichier de données car il
faudrait le faire à chaque changement d’une donnée concernée !

J’ai lu en diagonal l’article de loi mais il me semble avoir lu que tu es censé figer ton fichier (en fin d’exercice) et être capable de pouvoir prouver qu’il n’y a pas eu altération ultérieure sur ton fichier passé cet archivage. (avec utilisation d’un checksum ou équivalent) A moins que j’ai rêvé cela… :wink:

Il n’y a pas de directive technique : à toi de mettre en œuvre le procédé que tu juges fiable pour la conservation des archives

Merci Jean-Michel et Manuel pour vos réponses …

c’est quoi un “checksun” en fait ? :oops:

Une lecture de cet alinéa :

  1. vous avez une facture de 100 pour le client A,
  2. vous avez un règlement du client A de 90 à J et vous le validez dans votre environnement,
  3. vous avez une règlement du client A de 10 à J+1 et vous le validez dans votre environnement.

le compte de A est soldé à J+1

MAIS vous constatez une erreur, en fait le client A a réglé 80 et 20, 3 solutions :

  1. laisser ainsi (c’est une erreur),
  2. modifier le règlement de 90 en 80 et de 10 en 20 (c’est une erreur et ce à quoi cet alinéa fait référence), car vous ne conservez pas l’origine vous la modifier,
  3. ajouter les écritures pour annuler 90 et 10 puis ajouter les écritures pour créer 80 et 20.

la méthode 3 conserve les données et elles sont inaltérables (même si cet aspect reste à détailler car en votre qualité de développeur vous ne pouvez garantir l’inaltérabilité d’un support physique).

Avez-vous une vision plus claire de cet article ?

: Louis PEYOT

MAIS vous constatez une erreur, en fait le client A a réglé 80 et 20,
3 solutions :

  1. laisser ainsi (c’est une erreur),
  2. modifier le règlement de 90 en 80 et de 10 en 20 (c’est une erreur
    et ce à quoi cet alinéa fait référence), car vous ne conservez pas
    l’origine vous la modifier,
  3. ajouter les écritures pour annuler 90 et 10 puis ajouter les
    écritures pour créer 80 et 20.

la méthode 3 conserve les données et elles sont inaltérables (même si
cet aspect reste à détailler car en votre qualité de développeur vous
ne pouvez garantir l’inaltérabilité d’un support physique).

J’aurais plus tendance à dire que la méthode 2 est la bonne si l’écriture comptable appartient à une période non validée … Juste conserver une trace de cette modification … (un log qui détaillerait toutes les interventions ??)

Par contre, si l’écriture appartient à une période validée, le méthode 3 doit s’imposer …

Difficile de définir le champ d’application de beaucoup de points de cette loi … sachant que sur les programmes de compta, on a cette notion d’écritures “provisoires” ou “validées” … :expressionless:

: Louis PEYOT

Une lecture de cet alinéa :

En fait, je n’ai pas de souci fonctionnel avec cet alinéa, ni avec la gestion de l’inaltérabilité.

Mon interrogation portait sur le sous-entendu qu’implique l’alinéa que je rappelle ici

Le logiciel de comptabilité ou de gestion ou le système de caisse doit enregistrer toutes les données d’origine relatives aux règlements. Il doit conserver ces données d’origine enregistrées et les rendre inaltérables.

En spécifiant explicitement qu’il faut conserver les données relatives aux règlements, on pourrait comprendre que les logiciels ne gérant pas les règlements, ne sont pas concernés par la loi !

Concrètement une facturation simple avec export vers une compta standard pour traitement des règlements pourrait ne pas être concernée par la nouvelle règlementation.

En même temps ça paraît étrange de ne pas verrouiller le système de facturation, si on veut vraiment lutter contre la fraude…

pas une période mais une écriture
comptablement une écriture ne se modifie pas

vous êtes supposés TOUT conserver
c’est un principe de base

: Sebastien BERNARD

c’est quoi un “checksun” en fait ? :oops:

https://fr.wikipedia.org/wiki/Somme_de_contrôleChecksum = Somme de contrôle>

Bonjour,

Je me joins à cette discussion car le dossier devient urgent et capital!

Moi, ce qui m’inquiète le plus, c’est cette signature électronique des documents PDF (factures, reçus…), qui doivent être verrouillés et inaltérables. Je ne sais même pas comment faire ça!

Je ne suis sur le dossier que depuis hier, donc j’espère qu’au fil des jours, je vais mieux comprendre les demandes et trouver des réponses avec mon code 4D… :pray:

J’opte aussi pour l’auto-certification.

C’est mon logiciel de gestion de camping qui est concerné.

Je copie le lien trouvé sur un autre sujet de ce forum (PC Soft) qui parlait de cette certification et donne des infos intéressantes et nombreuses:
http://forum.pcsoft.fr/fr-FR/pcsoft.fr.windev/178777-certification/read.awp

Et l’article officiel du gouvernement destiné aux utilisateurs finaux de vos logiciels (article sans détails techniques informatiques):
https://www.service-public.fr/professionnels-entreprises/actualites/A10279

Bonjour Olivier et merci de te joindre à la discussion …

Une collègue (Expert-Comptable) a croisé l’un des ses clients qui est revendeur informatique. Ce dernier lui a a précisé que pour être en mesure d’auto-attester un logiciel, l’entreprise qui le fait doit
avoir le code NAF des éditeurs et développeurs de logiciels…

Avez-vous des précisions là dessus ?