Discussion :

[land willys]

Bonjour
La communauté des développeurs sous MSACCESS a un défi majeur à relever d'ici le 1er janvier 2018. Il s'agit de répondre aux nouvelles normes de l'administration fiscale (et ils ne sont pas avares de ce côté) qui permettrait, dès lors que les solutions que nous avons développées touchent la gestion ou la facturation de l'entreprise, d'assurer l'intangibilité des écritures permettant l'établissement de factures, règlements et autres éléments liés. Cette intangibilité devra être assurée par une certification délivrée par un organisme officiel ou par une déclaration en bonne et due forme auprès de l'administration. D'une façon générale, avez-vous commencé à réfléchir aux moyens d'assurer cette intangibilité ?

[marot_r]

d'assurer l'intangibilité des écritures

Bigre c'est tout un mandat, vu qu'avec un simple Excel on peut modifier les données de n'importe quel enregistrement sans aucune trace.

Personnellement j'ai toujours dit que mes logiciels étaient des "aides à", les données pour l'administration fiscale devaient provenir d'un logiciel de comptabilité où les informations fournies par Access étaient "stokées" (par copie automatique ou recopie manuelle) dans ce logiciel ou livre de comptes.

A+

[ClaudeLELOUP]

Bonjour,

Peut-être une piste de réflexion

Dans l’application, déterminer les tables qui pourraient trahir le fait que des éléments ont été ajoutés, supprimés ou modifiés.
J’utilise la méthode des journaux auxiliaires. Dans mon cas, il s’agit donc des tables source des formulaires qui servent à l’encodage des opérations (Banque, Caisse, Facturiers…).

Si dans ces tables, on a une colonne NuméroAuto et une colonne qui stocke systématiquement l’instant de création ou de modification de l’enregistrement, le fait :
- que le classement des enregistrements dans l’ordre chronologique correspond à l’ordre de la colonne NuméroAuto
et
- que les NuméroAuto sont consécutifs
devrait permettre de convaincre l’Administration que la comptabilité est régulière.

[marot_r]

Bonjour.

Je vais faire mon "casseur de party" mais comment garantir que les tables de journaux n'ont pas été altérées ?

A+

[ClaudeLELOUP]

Bonjour Marot,

Par exemple en fournissant une version compilée à l'utilisateur.

Tu me diras que le concepteur aurait toujours la capacité de trafiquer la date dans la table pour camoufler une modif, mais ça, c'est vrai pour n'importe quel logiciel si le concepteur se rend complice de fraudes !
Note que ça ne concerne que les modifs : pas les ajouts ni les suppressions.

[marot_r]

Oui, en effet et avec des macros de données (trigger) sur les tables on a une couche de plus de protection même si on ne peut pas les utiliser sur tous les types de champ.

Ça reste quand même fragile.

Peut-être en mettant les données dans un répertoire où seule l'application a accès ? Est-ce possible ?
Si oui, cela bloquerai les accès via Excel par exemple.

A+

[argyronet]

Bonjour,

J'attendais le premier post avant d'intervenir à mon tour...
C'est un suijet intéressant et il est sans doute important que tout un chacun apporte ces idées, points de vue et conviction sur la chose.

Cette intangibilité devra être assurée par une certification délivrée par un organisme officiel ou par une déclaration en bonne et due forme auprès de l'administration

Par cette citation, je me pose la question de savoir qui sera habilité à assurer cette certification et sur quels critères se basera t-il pour qualifier ou non que l'application/programme est aux normes ?

Sur le principe et avec ma «veille» expérience sur le traitement des données, il est évident qu'un gros travail va être de mise déjà sur les logiciels commercialisés (grand public pour TPME ou professionnel) avant d'attaquer les développement « maison ». Sauf erreur de ma part, il n'est à ma connaissance pas encore établi de norme (type ISO TrucMuche et tutti quanti) qui interpelle les développeurs à cela pour l'instant et qui les obligerait à ce plier à cette règle dans leur developpements.

Par ailleurs, cela ne concerne pas qu'Access ; tout type d'outil de dev. attaquant des bases de données [>...] traitant ce type gestion seront concernés.

Argy

[land willys]

Bonjour,

Peut-être une piste de réflexion

Dans l’application, déterminer les tables qui pourraient trahir le fait que des éléments ont été ajoutés, supprimés ou modifiés.
J’utilise la méthode des journaux auxiliaires. Dans mon cas, il s’agit donc des tables source des formulaires qui servent à l’encodage des opérations (Banque, Caisse, Facturiers…).

Si dans ces tables, on a une colonne NuméroAuto et une colonne qui stocke systématiquement l’instant de création ou de modification de l’enregistrement, le fait :
- que le classement des enregistrements dans l’ordre chronologique correspond à l’ordre de la colonne NuméroAuto
et
- que les NuméroAuto sont consécutifs
devrait permettre de convaincre l’Administration que la comptabilité est régulière.

Bonjour

Cela ne me semble pas suffisant car rien n'empêche la modification des montants (HT d'une ligne de facturation par exemple) dans les zones correspondantes. Je crains qu'il faille aller beaucoup plus loin.

[land willys]

Bonjour,

J'attendais le premier post avant d'intervenir à mon tour...
C'est un suijet intéressant et il est sans doute important que tout un chacun apporte ces idées, points de vue et conviction sur la chose.



Par cette citation, je me pose la question de savoir qui sera habilité à assurer cette certification et sur quels critères se basera t-il pour qualifier ou non que l'application/programme est aux normes ?

Sur le principe et avec ma «veille» expérience sur le traitement des données, il est évident qu'un gros travail va être de mise déjà sur les logiciels commercialisés (grand public pour TPME ou professionnel) avant d'attaquer les développement « maison ». Sauf erreur de ma part, il n'est à ma connaissance pas encore établi de norme (type ISO TrucMuche et tutti quanti) qui interpelle les développeurs à cela pour l'instant et qui les obligerait à ce plier à cette règle dans leur developpements.

Par ailleurs, cela ne concerne pas qu'Access ; tout type d'outil de dev. attaquant des bases de données [>...] traitant ce type gestion seront concernés.

Argy

Bonjour Argy
Je me suis "amusé" à lire le texte de la norme que chacun pourra trouver à cette adresse et ouvrir les liens de l'administration fiscale

http://www.synpell.fr/data/2016-04-0...%20synpell.pdf


Les mécanismes de certification sont expliqués. Pour mes propres solutions, j'utilise des interfaces avec des comptabilités du marché (Isacompta, EBP, CIEL, SAGE, etc.) et pratiquement tous sont déjà aux normes. Et les vieux clients qui n'ont pas fait évoluer leur logiciel comptable (en conservant de vieilles versions) sont sollicités pour se mettre à jour.

Personnellement je suis en train de réfléchir à une solution qui permettrait de crypter les zones sensibles dans les tables concernées. C'est une vieille méthode qui a fait ses preuves. Reste à trouver une solution de cryptage pas trop gourmande et relativement incassable.

[argyronet]

Bonjour,

Personnellement je suis en train de réfléchir à une solution qui permettrait de crypter les zones sensibles dans les tables concernées. C'est une vieille méthode qui a fait ses preuves. Reste à trouver une solution de cryptage pas trop gourmande et relativement incassable.

Oui, empêcher l'accès aux tables ou dissuader quiconque qui peut les ouvrir de comprendre le contenu reste la meilleure solution.

Argy

[marot_r]

Bonne idée le cryptage même si cela va compliquer la saisie et l'exploitation des données.

un bon cryptage facile est le XOR avec une chaine assez longue (ex 255 de caractères aléatoires sans blancs et figée dans le code) il est quasiment impossible à casser. Pour les champs mémos on peut pousser jusqu'à 32000.

On fait laChaine XOR lachaineDeCriptage pour encrypter et laChaine XOR laChaineDeCriptage pour décrypter en travaillant caractère par caractère.

A+

[nico84]

Bonjour,

Pour mes propres solutions, j'utilise des interfaces avec des comptabilités du marché (Isacompta, EBP, CIEL, SAGE, etc.) et pratiquement tous sont déjà aux normes. Et les vieux clients qui n'ont pas fait évoluer leur logiciel comptable (en conservant de vieilles versions) sont sollicités pour se mettre à jour.

J'ai aussi une transmission hebdomadaire des données de facturation et paiement à une comptabilité extérieure, ce qui interdit ensuite de modifier les données d'origine. Est-ce suffisant ?

A la lecture du projet de document de l'administration, j'ai le sentiment que si mon comptable a un logiciel certifié cela répond à la problématique, même si en amont les données ne sont pas "gravées dans le marbre". Par contre je ne suis pas sûr que son logiciel le soit

Par ailleurs mon logiciel stocke ses données sur une base MSQL qui tient un journal de tous les évènements. Si ce journal est conservé 6 ans, cela semble correct

Le projet précise au § I.C.1

Il appartient à (...) l'éditeur d'en demander la certification à un organisme accrédité

Quelqu'un connait un tel organisme et/ou a idée de ce que ça coute ?

[loufab]

Bonjour,

Un article intéressant et un avenir très sombre pour nous développeurs indépendants.

https://philippe.scoffoni.net/loi-fi...ilite-caisses/

Vive le lobbysme en politique !

[land willys]

Bonjour,

Un article intéressant et un avenir très sombre pour nous développeurs indépendants.

https://philippe.scoffoni.net/loi-fi...ilite-caisses/

Vive le lobbysme en politique !

Ce qui est 'amusant' dans cette analyse c'est de comparer l'intangibilité des écritures avec la versatilité des gouvernements.

[land willys]

Bonne idée le cryptage même si cela va compliquer la saisie et l'exploitation des données.

un bon cryptage facile est le XOR avec une chaine assez longue (ex 255 de caractères aléatoires sans blancs et figée dans le code) il est quasiment impossible à casser. Pour les champs mémos on peut pousser jusqu'à 32000.

On fait laChaine XOR lachaineDeCriptage pour encrypter et laChaine XOR laChaineDeCriptage pour décrypter en travaillant caractère par caractère.

A+

Bonjour

C'est effectivement une excellente solution. Alliée au cryptage de la base ACCESS c'est pratiquement infalsifiable. il reste à trouver l'organisme certificateur....

[nico84]

Bonjour à tous,

2 pistes de réflexion pour avancer sur le sujet :
- pour répondre au problème, un webinaire organisé par windew conseille d'ajouter une clé de type "hash" qui verrouille les données de facture
- je me demande si on ne peut pas se contenter d'enregistrer un pdf de la facture dans un coffre-fort numérique ? Si l'enregistrement est réalisé lors de l'émission de la facture et reste conforme à la facture encore dans la base cela me semble infalsifiable.

[User]

Bonjour à tous,

On approche doucement de 2018 et c'est toujours le brouillard complet concernant ces normes

Cdlt,

[chrtophe]

Tout à fait, ça va être le même bordel qu'avec la DSN.

Comme d'habitude, les gens honnêtes seront emmerdés et les fraudeurs continueront de frauder.

[User]

Bonsoir,

Normalement le but c'est de sanctionner sévèrement ceux qui fraudent, mais pas ceux qui ont seulement la possibilité de le faire...

Cdlt,

[nico84]

Bonjour,

Il y a quand même eu des nouvelles infos cet été qui précisent que cela concerne uniquement les ventes aux particuliers.

Cela fait que je ne suis plus concerné Pourvu que ça dure...