Donnés de Caisse "inaltérables" ???

Donnés de Caisse "inaltérables" ??? - C#/.NET managed - Programmation

Marsh Posté le 24-01-2018 à 14:47:15    

Bonjour,
 
On me demande s'il est possible de réaliser un logiciel de caisse (à côté de ma compta et de ma facturation).
 
Quand je consulte les nouvelles obligations de ce genre de logiciels au 1 Janvier 2018 je vois qu'il faut garantir une "inaltérabilité absolue" de bas niveau des données enregistrées, même vis à vis d'un pro...
 
Je me demande comment il est possible de faire cela au niveau des enregistrements...
 
Un simple cryptage de la base avec une clé spécifique à la boite est il suffisant ?
 
Savez vous comment on peut résoudre ce problème (et si cela vous paraît effectivement possible) ?
 
 :??:  
 

Reply

Marsh Posté le 24-01-2018 à 14:47:15   

Reply

Marsh Posté le 24-01-2018 à 16:31:35    

Pas sûr de bien comprendre la question :o

 

Comme j'ai du mal avec la question, quelques pistes de réflexion :

 

Le truc fondamental en eCommerce par exemple c'est déjà que tes factures/tickets doivent être stockés de manière complètement hermétique à ton catalogue "vivant". Genre pour extraire le détail d'une facture tu ne dois jamais avoir besoin de faire "vas chercher le produit X dans le catalogue", tu dois avoir stocké dans la facture elle-même et ses tables liées TOUTEs les infos indispensables du produit au moment de sa commande.
A l'extrême tu dois pouvoir rafficher toute la fiche produit telle qu'elle était lors de l'achat.
Etc.

 

Ca c'est au niveau "modèle de données".

 

Si tu veux une sécurité à un niveau plus physique, tu peux crypter ou serialiser en binaire certains éléments (c'est beaucoup plus chiant d'aller modifier un truc en binaire qu'un champ numérique/texte), restreindre les droits d'accès à la BdD (y compris pour les DBAs, il y a des moyens d'être DBA d'une base mais sans pouvoir accéder au contenu proprement dit), etc. Mais dans un SGBDR même si tu empêches l'altération, la suppression/dégradation reste "possible" tant qu'il y a des utilisateurs qui y ont accès...

 

L'inaltérabilité absolue c'est pas réaliste en informatique.

Message cité 1 fois
Message édité par TotalRecall le 24-01-2018 à 16:34:05

---------------
Réalisation amplis classe D / T      Topic .Net - C# @ Prog
Reply

Marsh Posté le 25-01-2018 à 13:34:41    

TotalRecall a écrit :

Pas sûr de bien comprendre la question :o
 
Comme j'ai du mal avec la question, quelques pistes de réflexion :
 
Le truc fondamental en eCommerce par exemple c'est déjà que tes factures/tickets doivent être stockés de manière complètement hermétique à ton catalogue "vivant". Genre pour extraire le détail d'une facture tu ne dois jamais avoir besoin de faire "vas chercher le produit X dans le catalogue", tu dois avoir stocké dans la facture elle-même et ses tables liées TOUTEs les infos indispensables du produit au moment de sa commande.  
A l'extrême tu dois pouvoir rafficher toute la fiche produit telle qu'elle était lors de l'achat.
Etc.
 
Ca c'est au niveau "modèle de données".  
 
Si tu veux une sécurité à un niveau plus physique, tu peux crypter ou serialiser en binaire certains éléments (c'est beaucoup plus chiant d'aller modifier un truc en binaire qu'un champ numérique/texte), restreindre les droits d'accès à la BdD (y compris pour les DBAs, il y a des moyens d'être DBA d'une base mais sans pouvoir accéder au contenu proprement dit), etc. Mais dans un SGBDR même si tu empêches l'altération, la suppression/dégradation reste "possible" tant qu'il y a des utilisateurs qui y ont accès...
 
L'inaltérabilité absolue c'est pas réaliste en informatique.


Je ne suis pas d'accord avec toi sur le principe de modélisation. le besoin est de retrouver les données telles qu'elles étaient au moment de l'achat. Rien ne t'empêche d'avoir, pour chaque produit, un historique des différentes versions d'informations. Ainsi, pour réafficher les données d'une facture, il suffit de récupérer la version dans laquelle se trouvait chaque produit à la date d'achat.


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Cantine Calandreta : http://sourceforge.net/projects/canteen-calandreta
Reply

Marsh Posté le 26-01-2018 à 22:42:39    

Conceptuellement ça pourrait aussi faire le job et limiter la redondance d'informations, mais en pratique dans la plupart des solutions e-commerce ça ne ressemble pas à ça il me semble.
A voir sur quelques cas concrets.

 

Mais là faudrait déjà que l'auteur du premier post se manifeste pour nous aider à comprendre de quoi il voulait parler...

Message cité 1 fois
Message édité par TotalRecall le 26-01-2018 à 22:43:11

---------------
Réalisation amplis classe D / T      Topic .Net - C# @ Prog
Reply

Marsh Posté le 09-02-2018 à 15:00:34    

TotalRecall a écrit :

Conceptuellement ça pourrait aussi faire le job et limiter la redondance d'informations, mais en pratique dans la plupart des solutions e-commerce ça ne ressemble pas à ça il me semble.
A voir sur quelques cas concrets.
 
Mais là faudrait déjà que l'auteur du premier post se manifeste pour nous aider à comprendre de quoi il voulait parler...


 
Bonjour, merci d'avoir pris la peine de répondre.
 
Je veux parler de ceci :
 
http://revuefiduciaire.grouperf.co [...] 48859.html
 
Qui induit, à priori, une notion "d'inaltérabilité" extrêmement sévère, car à assurer pas seulement au niveau de l'utilisateur final, mais aussi de l'intervention éventuelle d'un "pro" voire d'un expert sur la base de donnée.
 
Va t'on être obligé de finir par mettre en place une techno de type blockchain chez l'épicier du coin ?
 
"L'inaltérabilité absolue c'est pas réaliste en informatique.", c'est ce qu'il me semble aussi... dès lors comment peut t'on traiter, en pratique, ce genre de nouvelles contraintes ?
 
 :jap:  
 

Reply

Marsh Posté le 09-02-2018 à 15:12:34    

Je pensais justement à une blockchain pour garantir qu'on puisse pas falsifier le contenu de la BD. Cela dit, il me semble qu'une blockchain non distribuée sur plusieurs machines, ça perd de son intérêt car plus facile à falsifier, je pense, vu qu'une seule machine est concernée et stocke l'info.


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Cantine Calandreta : http://sourceforge.net/projects/canteen-calandreta
Reply

Marsh Posté le 21-02-2018 à 22:29:01    

Dans mon ancien job, on appelait les pays qui imposaient ces systèmes des pays "fiscaux", c'est à dire qu'ils avaient des spécificités telles qu'il était impossible de développer en interne les outils d'encaissement. Cela allait par exemple de l'utilisation d'un boitier de communication avec les serveurs centralisés de collecte de la TVA du gouvernement à la gestion d'imprimantes spécifiques ou d'appels à des services web qui généraient automatiquement les n° de facture (c'est à dire que nous n'avions plus la main sur ces identifiants).
 
Ces pays procédaient, environ 6 mois dans l'année, à des contrôles aléatoires sur les systèmes, et passaient les autres 6 mois à créer de nouvelles réglementations à mettre en place pour l'année suivante.
 
Même si nous ne sommes pas encore à ce niveau de suspicion dans la loi, les informations liées à cette dernière semblent quand même indiquer que le développement personnel d'un système d'encaissement en France tend à devenir impossible (https://www.addictgroup.fr/caisse-enregistreuse-obligatoire/) puisqu'une certification est apparemment nécessaire (le lien que j'ai donné est celui d'une entreprise qui propose des solutions, il y a peut être un peu d'alarmisme dans le discours mais c'est la tendance que les pays suivent).


Message édité par Tibar le 21-02-2018 à 22:29:44
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed