Logo ANAP
Ce site requiert l'activation de javascript pour être utilisé, merci de l'activer.

Espace de discussion

Filtrer sur le thème :

Cadre Juridique autour du schema de base de données

Messages

Par RODOLPHE TONNERRE le 20/03/2019 à 13:55

Bonjour à tous,


je cherche à savoir s'il existe un cadre juridique autour de la fourniture par un éditeur du schéma de base de données d'une application à son client.

Par ailleurs, l'accès aux données peut-il être interdit par l'éditeur, y compris en simple lecture pour des besoins de requêtage à objectif décisionnel ?

Je vous remercie pour votre collaboration et vos réponses.

Cordialement

Rodolphe TONNERRE

Par Christian VIALLON le 20/03/2019 à 18:45

Bonjour,

Une base de données est considérée juridiquement comme une oeuvre de l'esprit cela depuis une loi du 1er juillet 1998 (Code de la Propriété Intellectuelle, art L. 112-3). Dans le CPI la base de données est définie comme "un recueil [...] de données [...] disposées de manière systématique et méthodique et individuellement accessible par des moyens électroniques ou par tout autre moyen".

De mon point de vue cela protège la conception et la structure mais non les données. Celles-ci sont votre propriété et vous devez pouvoir en disposer. L'éditeur ne peut donc vous opposer un refus brutal. En revanche il risque de mettre en avant le risque que votre requête peut faire peser sur l'intégrité des données stockées dans la base. Mais les solutions techniques existent qui permettent d'isoler le requêtage et de ne faire courir aucun risque à la structure de la base et/ou à la sécurité des données. Le reste est, de mon point de vue, affaire de négociation commerciale.

Bien cordialement,

Christian Viallon

Par Christian VIALLON le 21/03/2019 à 07:33

Une précision complémentaire. L'article L. 342-1 du Code de la Propriété Intellectuelle énonce les droits des producteurs de base de données. Parmi ceux-ce figurent le droit d'interdire "l'extraction, par transfert permanent ou temporaire de la totalité ou d'une partiequalitativement substantielle du contenu d'une base de données sur un autre support et sous toute forme que ce soit". Enoncé comme tel ce droit est très proche du droit d'auteur. La Cour de Justice de l'Union Européenne (aff C-304/07 du 9 oct. 2009) a défini l'extraction comme "tout acte non autorisé [c'est moi qui souligne] d'appropriation de tout ou partie d'une base de données". Cela exclut la simple consultation à titre d'information. De mon point de vue vous disposez donc de 2 voies de recours. L'une non consensuelle consistant à considérer que votre extraction s'apparente à une simple information, l'autre consensuelle visant à obtenir l'autorisation. De ce point de vue vous êtes le client et vous êtes en position de force.

Par Emmanuel ELIE le 21/03/2019 à 08:45

Bonjour,

Au-delà d'une éventuelle bataille juridique avec un éditeur, je vous encourage à considérer la méthode de requêtage sur une base clone de la base source même si la mise à jour du clone ajoute un petit délais dans l'actualisation des données.

En effet, un accès, même en lecture seule, est une sollicitation de charge sur le logiciel de l'éditeur et donc, potentiellement une faille dans la réactivité de ce logiciel. Décharge le logiciel de sollicitation externes, en requêtant sur un clone est la méthode utilisée par les bons DataMart des éditeurs. D'ailleurs, la mise en place d'un tel clone devrait se faire avec l'aide de l'éditeur.

Si pour un accès en écriture, l'éditeur pourrait décliner toute responsabilité au titre de la maintenance. Sur un accès en lecture, il pourrait aussi renoncer à ses obligations de réactivité de support ou même de simple instruction des problèmes, du fait que son logiciel, qui comporte aussi des accès à la bases de données, se retrouverait altéré dans son architecture.

Un simple retard dans le traitement d'une chaine de données, peut parfois générer un disfonctionnement qu'il est très difficile d'identifier rapidement.

Enfin, l'éditeur reste maitre de son modèle de données et ne peut garantir sa stabilité entre les différentes versions. L'effort de maintenance de vos requêtes, qui sont donc votre propre développement, ne doit pas s'immiscer dans la relation contractuelle que vous entretenez avec l'éditeur.

A l'heure des multiples sollicitations pour projets autours de l'IA et des données de santé, être au clair sur les implications et obligations de chaque partie me semble crucial.

Par Grégory MORIN le 21/03/2019 à 12:13

Bonjour Rodolphe,

Les réponses données sont déjà très précises. Je peux toutefois te faire part de l'expérience de mon établissement concernant l'accès aux données des logiciels.

Dans le cadre du renouvellement de notre DPI, j'ai demandé explicitement dans le cahier des charges un accès en lecture seule à la base de données mais également l'accès au schéma de la base tout au long des mises à jours du logiciel. Les éditeurs, qui ont répondu au cahier des charges, détournaient cette demande en répondant qu'ils pouvaient donner un accès via des vues, ou encore des univers BO mais que les requêtes seraient soumises à prestations. Hors, je pense que nous sommes d'accord, nous souhaitons interroger et croiser nos données comme nous le souhaitons selon nos besoins. J'ai fait en sorte que cette demande de fonctionnalité, bien éloignée des fonctionnalités premières d'un DPI, soit soumise à une forte pondération afin de faire pression sur les éditeurs.

Finalement, l'éditeur retenu a donné un accès en lecture seule et un accès au schéma de base en se dégageant toutefois de toutes responsabilités en cas de disfonctionnements techniques ou fonctionnels induits par une requête trop consommatrice en ressources systèmes.

En conclusion, pour tes prochaines acquisitions de logiciel, je te conseille d'inscrire cette demande dans ton cahier des charges. A défaut, tu peux demander un avenant à tes éditeurs actuels via le meilleur moyen de pression que tu trouveras.

Bonne chance.

Grégory.

Par Thérèse PSIUK le 25/03/2019 à 15:48 Animateur de groupes

bonjour à tous. lorsque les chemins cliniques par groupes homogènes de patients sont informatisés dans le DPI, les requêtes sont indispensables à partir des écarts et des sorties de chemins cliniques pour les patients intégrés dans ce chemin clinique; nous avons un excellent exemple de gestion des requête au centre oscar lambret à lille ou par un simple clic la directrice de l'organisation des soins a accès immédiat aux requêtes avec des informations sur le nombre de partients sortis de tel chemin clinique et quelles cibles sont intégrés dans ces sorties; à partir de ces infos des décisions sont prises par les équipes pluridisciplinaires de terrain pour améliorer les soins (démarche d'amélioration continue de la qualité); lors de la synthèse avec ma communauté de pratique "informatisation des CC" nous avons préciser qu'il était indisoensable d'inscrire le requettage dans les cahiers des charges DPI.

Par RODOLPHE TONNERRE le 25/03/2019 à 16:08

Bonjour à tous

et premièrement, je voudrais vous remercier d'avoir pris un peu de temps pour faire avancer ce sujet.

Je suis d'accord avec @gregory, nous avons besoin, ou plutôt, nos utilisateurs ont besoin de croiser des données, de créer des tableaux de bord de suivi d'activité, etc. ...
La base répliquée me va bien, mais de plus en plus, les données doivent pouvoir être obtenues le plus proche possible du temps réel, pour prendre les bonnes décisions, parfois même dans l'urgence (tension en lits, épidémies, retrait de lots de produits par exemple).

Certains éditeurs intègrent un requêteur à leur application, permettant d'interroger la base de données de Production uniquement en lecture (SELECT xxxx). Aucune modification de données n'est donc possible, et l'usage est possible par des ressources "métier". (pas de requête UPDATE ou DELETE).

Je suis surpris que certains éditeurs ferment totalement les portes en 2019, à l'heure du pilotage par la donnée.

Rodolphe TONNERRE

Anonyme
Glissez-déposez une pièce jointe à la discussion
Haut de page