Salut la communauté,
Je vois de plus en plus de développeurs s’intéresser a des IA privées et extracommunautaire.
A la orée d’une évolution majeure de l’informatique qui m’inquiète un peu je dois le dire concernant la protection de la vie privée et une vision utilitariste des données la concernant, je constate que dolibarr en version stock résiste bien a cette tendance.
Néanmoins, lutter contre le courant est parfois plus dur que de l’accompagner.
Serait il temps de doter notre erp préféré d’une fonction dédié a l’usage permettant de filtrer un objet pour l’anonymiser et de permettre les traitements ia sans exposer les données sensibles ?
Cela ne protegera des produits et extentions véreuses mais permettrai au moins aux créateurs vertueux d’avoir la certitude que la donnée est clean.
bonjour @lucdennery
un peu dans cette idée Une autre approche de l'intelligence artificielle ?
moi en tout cas je suis « dedans » depuis des années mais le résultat est que grosso-modo personne ne participe vraiment et/ou « tout le monde s’en fout » voir pour des choses aussi simples et basiques que des tickets de carburants …
donc « filtrer » un objet pour le rendre « anonyme » … pourquoi pas mais dans le fond quel est le niveau d’anonymisation visée et le résultat sera t il exploitable ?
par exemple la donnée à anonymiser qui semble évidente avant de laisser « fuiter » ses données seraient les coordonnées bancaires (rib présents éventuellement sur certaines factures), les coordonnées du client et/ou du point de livraison etc.
mais c’est justement ce qui est intéressant de faire apprendre à une ia pour qu’elle puisse ensuite vous apporter une véritable aide lorsque vous allez verser vos données dans votre dolibarr : reconnaissance automatique du tiers, détection des modes de paiements, alerte de modification du rib de votre fournisseur (et donc en ce cas vérifiez qu’il a bien changé de rib et que ça n’est pas une « arnaque au faux rib ») etc.
donc faire « clean » en « anonymisant » je pense que le résultat ne sera pas à la hauteur
notre direction est maintenant de proposer à nos utilisateurs de nous confier temporairement leurs données couvertes par un contrat d’échange de données et offrant le plus possible de garanties techniques (données chiffrées avant de partir et déchiffrées chez nous le temps du traitement) pour les transmettre à l’ia le temps de l’apprentissage
ça me semble possible du fait que nous sommes à notre sens « digne de confiance » (voir notre historique, notre implication dans le libre sans faille depuis +20 ans etc.), que nous proposons ce genre de choses à nos clients/utilisateurs sans les forcer … mais c’est tout ce que nous pouvons faire
Je regarde avec interet vos travaux concernant l’ia, et je suis aussi en train de rassembler mes facturettes de carbu pour nourrir la bestiole.
Néanmoins je ne suis pas inquiet de solution comme la votre vertueuse en terme de données, mais plutôt d’une protection by design de certaine données dans dolibarr lors du développement d’applications avec la possibilité d’empêcher certain modules d’y accéder.
Je vois bien le problème de config que cela pourrai représenter, mais lorsqu’ aujourd’hui on appelle un objet (genre une facture ou autre), de nombreuse données sont présentes.
L’idée qui me vient sans trop de réflexion serait une modèle à l’android où l’utilisateur autorise une application, à accéder à tel ou tel type de données.
Quand il s’agit d’exfiltrer des données pour traitement soit par service tierce, la possibilité d’empêcher le module custom qui fait le traitement de sortir des données protégées par le RGPD par exemple, serait salutaire pour la suite de l’aventure de dolibarr dans le ce petit monde gourmand et intéressé en données personnelles
Le malheur à ce niveau c’est le risque « usine à gaz » que ça représente … déjà qu’on est pas super clair sur la « propagation des droits » lorsqu’un utilisateur externe est lié à un projet avec des combinaisons de « droits » entre les différents éléments de dolibarr …
J’ai conscience du problème qu’une api interne d’accès aux objets rajouterai une couche de droit parfois contradictoire et une difficulté croissante du maintien du core et des extentions (vertueuses).
Par ailleurs on touche aussi du doigt le problème ou l’avantage du libre ouvert, avec des modules externes, dont le code (ouvert) pose un problème d’analyse par manque de temps et/ou de compétences, qui accèdent à des données parfois sensibles soit par hook, soit par requête direct sans qu’il soit possible de vérifier ce qui est sorti ou rentré en temps réèl .
Exemple (absurde) avec l’outil de base SIRENE d’openDSI en imaginait qu’elle ferait du facebook en revendant la liste des société validées associées dans l’appelle de l’API au titulaire du dolibarr. Le tout pour financer le développement du module, ou avec les données bancaires, avec leur système d’import.
Au final la question est de savoir comment protéger efficacement les données d’un dolibarr. des exfiltrations externes, même dans un but louable comme l’usage d’api tierces pour obtenir de la data ou réaliser des traitements automatisés.
Oui mais non, car il suffit qu’un seul utilisateur découvre l’embrouille pour que le fournisseur en question soit cramé … raison de plus de faire plutôt confiance aux modules des éditeurs reconnus, présents depuis longtemps et impliqués dans la communauté.
Dans tous les cas il faut savoir où placer le curseur, les documents produits par dolibarr partent à un moment où un autre, ne serait-ce par exemple que chez votre expert comptable … lequel est probablement sous windows et utilise un antivirus. De là tout est dit 
Mais ce n’est pas une raison pour être rigoureux et faire le maximum.
Bonjour,
C’est exact, mais la protection de ces données est alors sous la responsabilité du comptable.
Il faut aussi préciser que si on installe Dolibarr et qu’il y a par exemple une faille dans Dolibarr qui entraine une fuite des données, on est pleinement responsable de cette fuite de données. Il s’agit d’un logiciel open source et il n’y a aucune relation contractuelle entre l’utilisateur et un « éditeur » dans ce cas.
Cela est différent si on utilise une solution SAAS pour Dolibarr, c’est dans ce cas le fournisseur du service qui est responsable de la protection des données.
Après avoir lu vos commentaires, je suis d’accord avec ce que quelqu’un a dit à propos du fait que c’est du « open source » (tout fait avec PHP) et qu’il peut donc y avoir une certaine « tranquillité » en ce qui concerne la confiance en Dolibarr et ses plugins.
Cela dit, une idée m’est venue : ce serait une bonne aide d’implémenter un JOURNAL (LOG) dans Dolibarr qui documente et permette de consulter TOUTES les requêtes SQL effectuées ?
Pour cela, il faut :
- forcer tous les modules à utiliser l’objet base de données global
$dbpour interroger la base de données - que Dolibarr stocke de façon chiffrée les données d’accès à la base de données au lieu de en texte brut dans le fichier
conf.php
Avec un tel journal, nous pourrions consulter les accès à la base de données lorsqu’un module tiers est utilisé, et évaluer une éventuelle « fuite de données personnelles/professionnelles ». De plus :
- Cela devrait pouvoir être activé/désactivé à volonté, de temps en temps, par exemple les premiers jours d’utilisation d’un nouveau module
- Un ensemble de règles pourrait être mis en place pour la détection de mouvements « inhabituels » (non habituels), soit avec des techniques « d’apprentissage automatique », soit avec un ensemble de règles préétablies, ou les deux.
Bref. Je dirais que la méfiance quant à l’API consultée par une IA (même si elle appartient à une entreprise privée) est excessive, sachant que nos données et celles de nos clients sont hébergées sur un serveur qui est généralement dans le centre de données d’une autre entreprise privée, et où en plus les données (clients, fournisseurs, facturation, etc.) NE SONT GÉNÉRALEMENT MÊME PAS CHIFFRÉES !!
Cela me amène à la conclusion d’@erics , qu’il faut surtout faire confiance à ses fournisseurs et à leurs contrats de confidentialité. D’une manière ou d’une autre, nos données doivent être manipulées ou stockées par une multitude de logiciels et d’« entreprises ».
Ne croyez pas que je suis DU GENRE CONFIANT, HEIN ! Justement à cause de ces sujets, je N’INSTALLE AUCUN PLUGIN de quelque type que ce soit dans mes navigateurs web, ni même de gestionnaires de mots de passe ! Donc personne ne se méprenne, j’accorde beaucoup d’importance à mes données, comme n’importe qui. Mais il faut aussi voir l’image globale et s’attaquer d’abord aux vulnérabilités les plus risquées. Et même ainsi, on n’aura jamais 100% confiance.
Le log ainsi que le chiffrement du mot de passe dans le fichier conf existe déjà. C’est d’ailleurs très précieux comme outils. Comme je disais, le logiciel étant open source, la structure des données étant documenté, il est tjr possible de requeter en direct, sans passer par les objets, mais ce n’est pas le fait de savoir qui me tranquillise, c’est de me dire qu’une extention bien codée, ne peut en aucun cas faire fuiter une donnée même contre sa volonté avec une protection par design des objets et non pas un protection par filtrage à posteriori.
