Messages les plus consultés

vendredi 13 juillet 2012

Les règles juridiques applicables à la constitution de fichiers de clients indésirables et listes noires

De nombreux organismes privés (entreprises, associations, syndicats professionnels) ou publics, quels que soient leurs domaines d’activité, constituent des fichiers recensant les mauvais payeurs, fraudeurs, ou personnes à risques. Ces listes d'exclusions, ou listes négatives, sont communément appelées "listes noires".

La position de la CNIL concernant ces types de fichiers a évolué avec le temps. Alors que la constitution de ces fichiers était quasiment interdite, car interdisant des catégories de personnes d’avoir accès à des produits ou services, la position de la Commission s’est assouplie, de manière assez pragmatique, afin de prendre en compte le développement de la fraude au paiement sur internet par exemple. C'est ainsi que, dans un rapport de 2003, la CNIL a publié plusieurs propositions et principes (information des personnes, proportionnalité, pertinence des informations collectées, durée de conservation raisonnable et sécurité des données) visant à encadrer de façon "plus réaliste" une pratique qui se généralisait dans tous les secteurs d'activité. (1)

Cependant, ces listes ont un impact direct sur la vie privée des personnes concernées, étant susceptibles de les exclure socialement (refus de vente ou de fourniture d’un service). La constitution de ce type de fichiers reste donc très encadrée par la loi.

Une récente délibération de la CNIL, concernant le Syndicat national des maisons de ventes volontaires (SYMEV) qui avait créé une liste noire d'acheteurs défaillants, sans respecter les conditions posées par la loi, nous donne l'occasion de rappeler les obligations légales pesant sur les organismes souhaitant constituer ces types de fichiers et les sanctions applicables en cas de non respect de ces obligations.


1. Quels types de fichiers sont constitutifs de "listes noires" ?

Une liste noire est un fichier rassemblant des données à caractère personnel (nom, adresse, numéro de carte bancaire, etc.) sur des personnes mises sous surveillance par un organisme, ou avec lesquelles l’organisme ne souhaite plus traiter en raison de la survenance antérieure d'incidents (par exemple, fraude ou incident de paiement). Une liste noire peut être interne à un organisme ou mutualisée entre plusieurs entités juridiques.

    1.1 Les fichiers concernés
Il existe une grande diversité de finalités et de contenus des listes mises en oeuvre. On retiendra notamment, parmi ces listes de personnes à risques ou indésirables :
    - les fichiers de clients douteux ou fichiers d'anomalies : par exemple lorsqu’un même client passe plusieurs commandes sur un site de e-commerce mais saisit plusieurs numéros de cartes bancaires et de téléphone et plusieurs adresses de domicile ;
    - les fichiers de fraudeurs : ces fichiers concernent des personnes ayant fourni de fausses informations (telles que fausse adresse ou numéro de carte bancaire, ou faux bulletins de paye), ou les fichiers de lutte contre la fraude au crédit ou à l'assurance ;
    - les fichiers d'auteurs de comportements répréhensibles : par exemple, les fichiers de conducteurs de véhicules de location ayant commis des infractions ;
    - les fichiers de mauvais payeurs : par exemple, les fichiers d'incidents de paiement ou de locataires mauvais payeurs. Ces fichiers sont courants en matière de vente en ligne ; dans ce cas l'acheteur ayant connu un incident de paiement se voit refuser la possibilité d'acheter ultérieurement sur le site web créditeur.

On peut citer également le fichier Preventel mis en oeuvre par le GIE Prévention Télécommunications. Ce fichier recense notamment les impayés dans le secteur de la téléphonie mobile. Les opérateurs de téléphonie mobile (tels Orange France, SFR, Bouygues Telecom, Auchan Telecom, etc.), membres du GIE, consultent le fichier Preventel chaque fois qu'une personne souhaite s'abonner à leurs services. Si la personne est fichée, l'abonnement peut lui être refusé ou un dépôt de garantie peut lui être demandé. (2)

    1.2 Les fichiers ne constituant pas des "listes noires"

Toutes ces listes ne sont cependant pas considérées comme des listes d'exclusion au sens de la loi.

Par exemple, les fichiers internes à une société, mis en oeuvre pour assurer le respect des obligations comptables, le traitement d'impayés, et le recouvrement des créances, peuvent être constitués sans autorisation de la CNIL. De même, un établissement ouvert au public (tel un établissement scolaire) peut constituer une liste de sites web bloqués à la consultation (réseaux sociaux, messageries, sites pour adultes, etc.).

Ces types de fichiers, ne comprenant pas de données à caractère personnel et ne visant pas à empêcher quelqu'un de bénéficier d'un droit, d'une prestation ou d'un contrat, ne sont pas considérés comme des listes noires.


2. Les obligations légales relatives à la constitution de "listes noires"


La constitution de listes de clients indésirables n’est pas illicite, à condition de respecter les dispositions légales que nous rappelons ci-après.

Un organisme privé ou public qui crée un fichier de clients indésirables met en oeuvre un traitement de données à caractère personnel (nom, prénom, adresse, numéro de téléphone, adresse e-mail, etc.). Un traitement de données personnelles consiste dans le fait de collecter, enregistrer, conserver, modifier, diffuser ou détruire des données personnelles.

Si l'organisme en charge du fichier est situé en France, celui-ci est tenu de respecter les obligations relatives aux traitements de données personnelles définies par la loi Informatique et Libertés, en sa qualité de responsable de traitement. (3)

    2.1 Les formalités préalables à la constitution d’un fichier de clients indésirables
La mise en oeuvre d’un fichier de clients indésirables (ou à risques) est soumise à l'autorisation préalable de la CNIL (et non à une simple déclaration). Le traitement ne pourra être mis en oeuvre avant d’avoir reçu cette autorisation, sachant que la CNIL peut demander des informations ou des engagements complémentaires à l’organisme demandeur si elle estime que la demande d’autorisation est incomplète ou qu’elle manque de précisions. (4)

Ainsi, l’exploitant d’un site de vente en ligne qui souhaiterait constituer un fichier automatisé de lutte contre la fraude au paiement ou un fichier de mauvais payeurs devra faire une demande d’autorisation préalable à la constitution d’un tel fichier à la CNIL.

Par ailleurs, des entités juridiques distinctes ont la possibilité de faire une demande d’autorisation de constitution de listes mutualisées. Ces organismes pourront ensuite communiquer entre eux des informations ou fichiers. Toutefois, afin d'éviter le risque d'exclusion résultant d'une centralisation d'impayés provenant de plusieurs secteurs d'activités confondus et de garantir la proportionnalité du traitement, la CNIL préconise que l'accès à ces listes soit limité aux professionnels d'un secteur déterminé.

Par exemple, les professionnels de la vente en ligne, tous secteurs confondus ne pourraient pas en principe constituer de telles listes. De même, si les professionnels de l'immobilier peuvent alimenter et consulter une liste commune de locataires mauvais payeurs, les particuliers propriétaires de biens immobiliers (non professionnels) ne peuvent y avoir accès.

    2.2 Les conditions de constitution du fichier
Pour qu’un fichier d’indésirables, ou liste noire puisse être accepté par la CNIL, celui-ci devra être régulièrement constitué et respecter les conditions posées par la réglementation.

Le caractère déterminé, explicite et légitime de la finalité du fichier - Tout fichier (ou traitement) doit avoir une finalité définie et précise (ex: lutte contre la fraude à l'assurance). Ainsi, un fichier ne peut porter que sur des données collectées pour des finalités déterminées, explicites et légitimes. Ces données doivent être adéquates, pertinentes et non excessives au regard de la finalité pour laquelle elles sont collectées.

A ce titre, la mise en oeuvre d'une liste noire doit être proportionnée et l'inscription sur une telle liste ne peut se justifier que pour un motif particulièrement grave, motivé et objectif. Ainsi, lorsque le fichier vise à recenser des informations sur des impayés non régularisés, la créance doit être certaine, liquide et exigible. Un seuil d'inscription peut être défini, notamment en cas de liste noire mutualisée à plusieurs organismes. Par exemple, les abonnés aux services de téléphonie mobile, débiteurs, ne peuvent être inscrits sur le fichier Preventel qu’à partir d’un montant impayé de 30€.

La conservation des données pour une durée "raisonnable" - Les données personnelles ne peuvent être conservées que pour une durée raisonnable. Au-delà de cette durée, les données doivent être soit effacées, soit anonymisées. Par durée raisonnable, on entend la durée nécessaire au traitement. Par exemple, en matière d'incidents de paiements, les données doivent être supprimées dès que les sommes dues ont été réglées. A défaut de régularisation, la CNIL préconise une durée de conservation comprise entre 2 et 5 ans (en fonction de la finalité du traitement, de l'identité du responsable de traitement, du caractère mutualisé ou non des informations, etc.).

L’obligation de sécurité des données - Compte tenu de la sensibilité de ce type de fichier, l'organisme qui met en oeuvre le traitement est soumis à une obligation de sécurité très forte pour empêcher que les données traitées soient erronées, modifiées, effacées par erreur, ou que des tiers non autorisés aient accès au traitement. L’organisme est tenu de mettre en oeuvre des mesures de sécurité physique (accès contrôlé aux locaux hébergeant les serveurs) et techniques (serveurs protégés par des firewalls, accès par mot de passe, éventuellement cryptage des données, etc.).

L'information et les droits des personnes concernées - Même en matière de fichiers de clients indésirables ou de fraude, la collecte de données personnelles ne peut être réalisée à l’insu de la personne concernée. Celle-ci doit notamment connaître l'identité du responsable de traitement, la finalité du traitement, l'identité des destinataires des données et des éventuels transferts de données hors Union européenne.

En matière de liste noire, l'information doit en principe se faire à plusieurs moments : (i) lors de la collecte des données (ex: au jour de l'inscription de l'internaute sur le site web ou de la conclusion du bail par l'insertion d'une clause au contrat), (ii) lors de la réalisation de l'incident susceptible de donner lieu à une inscription (information individuelle par courrier) et (iii) lors de l'inscription effective (un délai raisonnable doit être prévu afin de permettre à la personne concernée de faire valoir ses observations).

Enfin, les personnes concernées bénéficient d’un droit d'accès (pour consultation), de rectification (en cas d'homonymie ou de régularisation de créance non prise en compte), de contestation et d'opposition (demande de suppression ou de désinscription en cas d'usurpation d'identité) au traitement de leurs données.


3. Quelles sanctions en cas de non-respect de la réglementation sur les données personnelles ?

Le non-respect par un organisme des règles applicables à la constitution et à la mise en oeuvre d’un traitement de données à caractère personnel est passible de sanctions qui peuvent être prononcées directement par la CNIL, ou par les juridictions pénales après transmission du dossier au procureur de la République.

    3.1 Les pouvoirs de contrôle de la CNIL
La CNIL dispose de pouvoirs de contrôle et de sanction à l'encontre des responsables de traitement en cas de non-respect des dispositions légales en matière de traitement de données personnelles.

Des contrôles sur place (dans les locaux de l’entreprise), peuvent être réalisés de façon inopinée ou à la suite de plaintes. Lors de ces contrôle, les agents de la CNIL (pouvant être accompagnés d’agents de la DGCCRF) peuvent demander communication de tout document, recueillir tout renseignement utile et accéder aux serveurs, aux programmes informatiques et aux données afin de vérifier la conformité des traitements à la loi Informatique et Libertés.

    3.2 Les sanctions applicables
Les manquements à la loi Informatique et Libertés sont passibles de sanctions pénales. Ainsi, le fait de procéder à un traitement de données personnelles (i) sans respecter les formalités préalables, y compris par négligence ou (ii) malgré l'opposition de la personne concernée, est puni de 5 ans d’emprisonnement et 300.000€ d’amende.

Les sanctions prononcées par la CNIL - Lorsque des manquements à la loi sont relevés, la CNIL peut prononcer un avertissement ou mettre l'organisme en demeure de faire cesser le manquement constaté dans un délai qu’elle fixe. Si l'organisme ne se conforme pas à la mise en demeure, la CNIL peut prononcer une sanction pécuniaire d'un montant maximum de 300.000€, une injonction de cesser le traitement ou un retrait de l’autorisation accordée.

Par exemple, en juin 2006, la CNIL a prononcé une sanction de 45.000€ à l’encontre du Crédit Lyonnais pour entrave à son action et inscription abusive de clients sur le fichier des "retraits de cartes bancaires (CB)", tenu par la Banque de France. En l’espèce, le Crédit Lyonnais avait inscrit des clients dans ce fichier relatif aux seuls incidents liés à l'usage de la carte bancaire, alors que les incidents concernaient l'utilisation de chèques sans provision et le défaut de règlement d'échéances de paiement de crédit. Ces incidents auraient pu justifier l'inscription des clients au fichier central des chèques (FCC) ainsi qu'au fichier des incidents de remboursement des crédits aux particuliers (FICP) mais en aucun cas au fichier des retraits "CB". (5)

Récemment, le 24 mai 2012, la CNIL a prononcé un avertissement rendu public à l'encontre du Syndicat national des Maisons de Ventes Volontaires (SYMEV). Le syndicat avait constitué une "liste noire" mutualisée informant les maisons de ventes volontaires aux enchères publiques de l'identité d'acheteurs (ou adjudicataires) défaillants. Dans cette affaire, la CNIL rappelle que si la constitution de listes noires n'est pas en soi interdite, sa mise en oeuvre doit respecter les principes posés par la loi, dès lors qu'elle est susceptible d'exclure des personnes de la faculté de participer à des ventes aux enchères. Or, la CNIL a constaté que la liste litigieuse avait été constituée sans son autorisation et à l'insu des personnes fichées. (6)

Les sanctions pénales - La Cour d'appel de Bourges a rendu une décision en janvier 2007 à la suite de la transmission du dossier par la CNIL au procureur de la République. Dans cette affaire, la Ligue européenne de défense des victimes de notaires avait publié sur un site internet une liste nominative de 2500 notaires, la page d'accueil du site indiquant que : la profession de notaires faisait courir “les plus grands risques aux clients” et que “le fait d’être inscrit sur la liste de la Ligue européenne de défense des victimes de notaires n’impliqu(ait) aucun préjugé ni pré-jugement ; cela implique que notre association a un dossier concernant un client ou plusieurs clients de l’étude de notaire”.

Or, le traitement de la liste nominative de ces notaires n’avait fait l’objet d’aucune demande d’autorisation préalable auprès de la CNIL. Plusieurs notaires s'étaient opposés, sans succès, à leur mention sur le site web. La Cour en a conclu que “le procédé informatique utilisé aboutissant de fait à la création d’une liste noire des notaires et s’apparentant comme tel à de la délation, est à l’origine d’un préjudice certain pour (les notaires fichés) qui, outre l’opprobre et la suspicion jetée publiquement, ont pu voir des particuliers se détourner (d'eux pour avoir été) injustement mis en cause". La Ligue et sa gérante ont été condamnées respectivement à 3.000€ et 1.500€ d'amende ainsi qu'au versement de 9.700€ aux parties civiles (100€ à chacun des 97 notaires plaignants). (7)


Ainsi, la constitution de fichiers de clients indésirables, à risques, de fraudeurs, etc. n’est pas interdite si la finalité du traitement est déterminée, explicite et légitime (telle la lutte contre la fraude). Il est cependant nécessaire de se conformer aux obligations légales de demande d’autorisation préalable à la CNIL et de constitution et mise en oeuvre dans le respect des dispositions de la loi Informatique et Libertés, sous peine d’être passible de sanctions pénales en cas de non respect de ces dispositions.

Outre les listes noires, les organismes peuvent avoir recours à la technique dite du "profilage" consistant à appliquer un profil à une personne physique et la placer ainsi dans des catégories de groupes prédéfinies, notamment à des fins d'analyse ou de prédiction de ses préférences, comportements et attitudes personnels. Cette pratique, toute aussi sensible dans la mesure où elle peut avoir pour conséquence d'exposer les personnes concernées à des risques de discrimination et d'atteinte à leur dignité, n'est pas soumise aux mêmes règles que celles des listes noires. (8)


* * * * * * * * * * *

(1) Les fichiers de type liste noire étaient admis dans les secteurs de la banque et du crédit (fichier des interdits bancaires par exemple), mais soumis à des conditions de suivi (inscription et radiation) strictes. Voir rapport de la CNIL de novembre 2003 : "Les listes noires : le fichage des "mauvais payeurs" et des "fraudeurs" au regard de la protection des données personnelles" (http://www.ladocumentationfrancaise.fr/var/storage/rapports-publics/034000689/0000.pdf)
(2) Voir site internet du GIE Prévention Télécommunications : http://www.preventel.fr/.
(3) Loi n°78-17 du 6 janvier 1978 relative à l’informatique, aux fichiers et aux libertés, modifiée, dite Loi Informatique et Libertés.
(4) En application de l’article 25 I (4e) de la loi Informatique et Libertés : “Tous traitements susceptibles, du fait de leur nature, de leur portée ou de leurs finalités, d’exclure des personnes du bénéfice d’un droit, d’une prestation ou d’un contrat en l’absence de toute disposition législative ou réglementaire" est soumis à une demande d’autorisation préalable à la CNIL.
(5) Délibération n°2006-174 du 28 juin 2006 prononçant une sanction pécuniaire à l'encontre du Crédit Lyonnais.
(6) Délibération de la formation restreinte n°2012-079 du 24 mai 2012 portant avertissement public à l'encontre du Syndicat National des Maisons de Ventes Volontaires (SYMEV).
(7) CA Bourges 2e ch., 11 janvier 2007, Gisèle L. et autres c/ Ministère Public.
(8) Exemples de profilage : dans un communiqué du 25/10/2011, la CNIL a dénoncé les techniques dites de " profilage communautaire" consistant à créer des fichiers faisant apparaître, directement ou indirectement, l'appartenance religieuse ou l'origine raciale vraie ou supposée des personnes. A ce titre, l'application pour iPhone dénommée "Juif ou pas juif", retirée de la vente en septembre 2011 est un exemple de ciblage communautaire. Dans un autre registre, la CNIL a souhaité encadrer de façon stricte la technique du "score" (ou instrument d'aide à la décision d'octroi ou de refus de crédit (analyse des risques) utilisé par les établissements de crédit) et a publié plusieurs délibérations à ce sujet (délibérations n°2006-019 du 2/02/2006 et délibération n°2008-198 du 9/07/2008).



Bénédicte DELEPORTE - Avocat
Betty SFEZ - Avocat

Deleporte Wentz Avocat
www.dwavocat.com

Juillet 2012

dimanche 24 juin 2012

Développement de site web, contrat et droit d’auteur : un projet informatique à gérer rigoureusement

Le site web est devenu un outil de communication incontournable pour la plupart des entreprises. Afin de concevoir son site, l’entreprise fait généralement appel aux services d’une web agency, prestataire spécialisé dans la conception, la réalisation et le développement de sites web.

L’entreprise peut décider de faire réaliser un site sur mesure, original et personnalisé, ou bien faire réaliser un site conçu à partir d’une maquette préexistante. En tout état de cause, et a fortiori en cas de site original, la réalisation du site web constitue un réel projet pour l’entreprise qui aura, en collaboration avec le web-développeur, pensé et conçu l’architecture, chaque page et chaque élément visuel et graphique du site.

La réalisation d’un tel projet nécessite la rédaction de documents contractuels clairs et complets ainsi que la prise en compte de la propriété intellectuelle du site. A défaut, d’une part, les parties prennent le risque de voir leur projet échouer, avec pour conséquence éventuelle l’engagement de la responsabilité du prestataire et, d’autre part, l’entreprise-cliente risque de ne pouvoir exploiter librement son site web.

Dans deux arrêts récents concernant respectivement un projet ayant échoué et une affaire de contrefaçon des droits du prestataire, les juges rappellent les principes et obligations applicables au projet de développement de site web et aux droits du développeur.


1. La nécessaire formalisation des besoins du client et des engagements du prestataire

La complexité des projets informatiques, y compris pour la réalisation de sites web nécessite non seulement l’élaboration de documents contractuels précis et exhaustifs mais également une réelle collaboration entre web-développeur et client.

    1.1 L’obligation de collaboration entre prestataire et client et l’importance des documents contractuels
Chaque projet, du plus simple au plus complexe, est unique.

Même pour les offres de création de sites standard, il conviendra de proposer un cadre juridique adapté, précis et clair. Les CGV devront indiquer clairement les prestations comprises dans la proposition, ainsi que les droits accordés au client (simple licence d’utilisation du site, ou cession des droits de propriété intellectuelle au client, qui aura ensuite la liberté de faire évoluer son site, avec ou sans recours au prestataire).

Les projets de développement de sites sur mesure doivent, pour leur part, être gérés comme de véritables projets informatiques.

Or, pour chaque projet, la collaboration est une obligation qui s’impose aux parties, prestataire et client. Pour le prestataire, cette obligation se traduit, avant même la signature du contrat de développement, par son devoir de conseil et d’information du client. Ainsi, au cas où les compétences techniques du client seraient limitées, le prestataire devra l’informer sur les éventuelles lacunes de la définition de ses besoins et de son cahier des charges, voire même l’avertir si les besoins définis sont particulièrement difficiles à atteindre, onéreux, ou irréalisables, et dans ce cas, proposer un recalibrage du projet. En outre, le prestataire devra tenir compte de la difficulté du projet dans la définition de ses engagements et la détermination du budget.

Parmi les documents indispensables à la bonne conduite du projet, les parties devront agréer un cahier des charges, un cahier de spécifications techniques et fonctionnelles et conclure un contrat de conception de site web. Ces documents formeront le cadre contractuel et le référentiel de travail du prestataire.

Le cahier des charges, document essentiel, doit recenser les besoins du client et présenter les objectifs poursuivis et les fonctionnalités attendues. Sur la base de ce document, le prestataire va définir ses modalités d’intervention et développer le site.

Le cahier de spécifications techniques et fonctionnelles consiste en la traduction, par le prestataire, des besoins du client tels qu’énoncés dans le cahier des charges.

Enfin, le contrat de conception ou de développement de site web devra notamment mentionner les étapes de la création du site, les obligations et les garanties fournies par le prestataire, les conditions relatives à la propriété intellectuelle (et éventuellement la cession au client des droits de propriété intellectuelle sur le site), le prix de la prestation, les délais d’exécution et la procédure de recette (préalable à la livraison définitive du site).

Ces trois documents sont trop souvent négligés par les parties, et source de conflit en cas de dérapage du projet de développement.

    1.2 L’exemple de l’échec d’un projet suite à son mauvais calibrage
Dans un arrêt de la Cour d’Appel de Paris du 16 mars 2012, les juges ont condamné un prestataire informatique suite à l’échec du projet de développement de site web sur lequel il était missionné.

En l’espèce, une société avait confié à un prestataire informatique la création d’un site web. Le contrat de développement comprenait deux phases : une première phase de réalisation d’un document de conception, suivie d’une phase de développement du site (plateforme multimédia). Au cours de la réalisation du projet, le prestataire, s’étant aperçu qu’il n’avait pas mesuré l’ampleur de la tâche à accomplir, a notifié au client que le montant du projet serait beaucoup plus élevé que prévu initialement (147.000€ au lieu de 47.000€). A la suite de quoi, les relations entre les parties se sont dégradées, le prestataire a rompu unilatéralement le contrat et le site web n’a pas été mis en ligne.

La Cour a relevé que les termes du cahier des charges et du contrat étaient trop imprécis :
- Concernant le contrat, les parties avaient employé une terminologie inadaptée. Il existait une ambiguïté quant à la nature de la plateforme à concevoir, le contrat mentionnant d’une part la livraison d’une plateforme au format bêta (1ère version non complètement testée ni recettée définitivement) et d’autre part une plateforme commercialisable (donc, validée techniquement) ;
- Concernant le cahier des charges, ce document contenait de nombreuses imprécisions, telles les mentions “à prévoir”, “à finaliser”, ou encore “en cours de construction”. Malgré ces imprécisions, le prestataire a accepté de s’engager contractuellement, a priori sans émettre de réserves particulières quant à la nécessité de calibrer le projet avant la signature du contrat, ou bien au fur et à mesure de l’avancée des développements.

Selon la Cour, le fait que le projet se soit avéré d’un niveau de complexité non anticipé n’autorisait pas le prestataire à résilier ce contrat de manière unilatérale. La simple consultation du cahier des charges devait lui permettre de se convaincre de son incapacité à réaliser le projet pour le montant contractuellement envisagé. Par ailleurs, le projet comportant de nombreux points non définis au moment de la signature du contrat, il aurait été nécessaire d’en définir le périmètre de manière plus formelle. La Cour a estimé que le prestataire avait commis une faute en rompant le contrat suite au refus du client de revoir le montant de la prestation à la hausse, et en étant incapable de proposer ne serait-ce qu’une version simplifiée du projet pour le montant convenu contractuellement.

La Cour a jugé la résiliation anticipée du contrat par le prestataire fautive et a condamné celui-ci à verser 30.000€ de dommages et intérêts à l’entreprise cliente. (1)

En conséquence, le projet de développement de site web doit être traité comme tout autre projet informatique. La réussite du projet passe par la prise en compte contractuelle des besoins techniques, des coûts afférents au développement du site, du calendrier de développement et de mise à disposition du site, des évolutions éventuelles, etc. Les parties devront porter une attention particulière à la rédaction des documents contractuels, et à la portée de leurs engagements respectifs.


2. L’exploitation du site web et la gestion des droits d’auteur


La question de la titularité des droits de propriété intellectuelle sur le site web et ses composantes est un autre aspect que les parties au contrat de développement de site web  ont souvent tendance à négliger. Ainsi, le client qui “achète” son site web à un prestataire n’acquière en réalité qu’un droit d’utilisation du site, en l’absence d’une clause de cession des droits de propriété intellectuelle pour le site et ses composants, juridiquement valable.

    2.1 En l’absence d’une clause de cession des droits d’auteur, le site web appartient à celui qui l’a développé
Pour rappel, le site web, en tant qu’œuvre de l’esprit, est protégé par le droit d’auteur, sous réserve d’être original, au sens du droit de la propriété intellectuelle.(2)

L’agence de web-développement (ou le prestataire indépendant), développeur du site web, est titulaire des droits d'auteur sur le site, ces droits comprenant les droits patrimoniaux et le droit moral.(3) En sa qualité d’auteur, le prestataire dispose d’un monopole d’exploitation, les créations ne pouvant être utilisées par des tiers qu’avec son accord. Toute atteinte aux droits d'auteur, telle une reproduction non autorisée ou une imitation servile, peut être qualifiée de contrefaçon.

La loi prévoit que “l’existence ou la conclusion d’un contrat de louage d’ouvrages ou de services par l’auteur d’une œuvre de l’esprit n’emporte aucune dérogation à la jouissance (de ses droits)” (article L.111-1 al.3 du CPI). Ainsi, même si un client “commande” le développement d’un site web à un prestataire, les droits d’auteur sur le site appartiennent à ce dernier.

Contrairement aux idées reçues, l’entreprise-cliente, par le simple fait de payer la prestation, ne devient pas automatiquement propriétaire de “son” site.(4) A défaut de contrat prévoyant la cession des droits d’auteur au profit de l’entreprise-cliente, le client ne disposera “que” d’un droit d’utilisation du site, le prestataire conservant les droits de propriété intellectuelle.

En outre, les sites web étant des oeuvres multimédia, intégrant du logiciel, des bases de données, du texte, des dessins et/ou des images ou photographies, voire de la vidéo et de la musique, plusieurs personnes (morales et/ou physiques) peuvent être impliquées dans leur développement informatique, graphique, etc. Ainsi, les sites web sont souvent des oeuvres de collaboration ou des oeuvres collectives.

Compte tenu de la complexité des droits des différents intervenants sur le développement du site (prestataire informatique, graphiste, photographe, et le client souvent l’auteur des contenus éditoriaux du site), il est impératif d’aborder la question des droits de propriété intellectuelle du site et de ses composants, a fortiori si le client-utilisateur souhaite effectivement acquérir les droits de propriété intellectuelle sur l’intégralité du site.

La cession des droits de propriété intellectuelle, pour être effective et opposable juridiquement, doit obligatoirement être constatée par écrit et respecter les conditions prévues par l’article L131-3 al.1 du Code de la propriété intellectuelle, qui dispose que : “La transmission des droits de l'auteur est subordonnée à la condition que chacun des droits cédés fasse l'objet d'une mention distincte dans l'acte de cession et que le domaine d'exploitation des droits cédés soit délimité quant à son étendue et à sa destination, quant au lieu et quant à la durée.”

    2.2 L’exemple d’une reproduction de site web non autorisée par le prestataire, censurée par les tribunaux

Une décision récente du Tribunal de grande instance de Paris a rappelé qu’un client faisant réaliser son site par une web agency, n’était pas titulaire des droits d’auteur, puisque l’auteur est le prestataire qui a développé le site.

En l’espèce, le client avait confié la création et l’hébergement du site à un prestataire. Quelque temps après, le prestataire a constaté la reproduction du site qu’il avait créé, sans son consentement, sous un autre nom de domaine. En outre, la mention de son nom avait été supprimée, en bas de la page d’accueil du site web, au profit d’un nouveau prestataire.

Or, les pièces communiquées (bon de commande, photographies, télécopies) ont permis de constater que le site web avait été mis en ligne avec mention du nom du premier prestataire et que celui-ci, et non le client, possédait les compétences requises en matière de création  et développement de sites web, avait conçu la présentation des différentes pages et l’agencement des éléments composant le site (graphisme, animation ou arborescence) et enfin disposait toujours des codes sources du site web.

Le Tribunal en a donc conclu que le client n’était pas titulaire des droits sur le site web (aucun accord de cession des droits n’ayant été conclu avec le client). Il ne pouvait donc le faire reproduire sans l’autorisation du premier prestataire. Le client a été condamné à verser 3.000€ au prestataire au titre de la contrefaçon.(5)


En conséquence, il appartient aux parties, prestataire et client, de ne pas négliger l’importance de la gestion des droits de propriété intellectuelle sur le site web à développer. En cas de cession des droits de propriété intellectuelle, celle-ci devra être constatée par écrit et détailler précisément les différents éléments et conditions de la cession, comme rappelé ci-dessus.


* * * * * * * * * * *

(1) Cour d’appel de Paris, Pôle 5, Ch. 11, 16 mars 2012 ; Sté Uzik c/ Sté Moralotop.
(2) Voir les articles L.111-1 et s., L.112-1 et s. et L.113-1 et s. du Code de la propriété intellectuelle. Selon la jurisprudence, l’œuvre est originale lorsqu’elle porte en elle “l’empreinte de la personnalité de son auteur” et traduit “un effort personnel de création”, ce qui distingue cette oeuvre des autres.
(3) Le droit moral correspond notamment au droit de paternité, permettant à l’auteur d’exiger la mention de son nom sur l’œuvre (s’il s’agit d’une personne morale, il s’agira de la dénomination de l’entreprise)
(4) TGI Paris, Ordonnance de référé du 27 septembre 2000 ; Sté Prosodi Corp. / GIE Summits.
(5) TGI Paris, 3ème ch., 4ème section, 10 novembre 2011, Victoriaa, Estelle G. / Linkeo.com, Stéphane C.



Betty SFEZ - Avocat

Deleporte Wentz Avocat
www.dwavocat.com

Juin 2012

jeudi 31 mai 2012

Les contours de la protection des logiciels par le droit d’auteur précisés par la CJUE

Par un arrêt du 2 mai 2012, la Cour de justice de l’Union européenne (CJUE) a rappelé les contours de la protection des logiciels par le droit d’auteur, en application des directives du 14 mai 1991 concernant la protection juridique des programmes d’ordinateur et du 22 mai 2001 sur l’harmonisation de certains aspects du droit d’auteur et des droits voisins dans la société de l’information.(1 et 2)

En l’espèce, la société SAS Institute Inc. est éditeur de progiciels analytiques permettant le traitement et l’analyse de données, notamment, les analyses statistiques. Ces progiciels (le système SAS) permettent aux utilisateurs d’écrire leurs propres programmes applicatifs (les scripts), dans un langage propre au système SAS, aux fins d’adapter le système SAS pour le traitement de leurs données. La société World Programming Ltd (“WPL”) a développé un logiciel de substitution, dénommé “World Programming System”, dont l’objet est d’exécuter les scripts écrits dans le langage SAS pour émuler les fonctionnalités des composants SAS. Les utilisateurs du système SAS pouvaient donc, grâce au logiciel World Programming System, utiliser les scripts développés pour être utilisés avec le système SAS, sans avoir à les réécrire.

SAS Institute a assigné WPL en contrefaçon de ses droits de propriété intellectuelle devant les tribunaux britanniques.

La High Court of Justice (England and Wales), Chancery Division, a posé plusieurs questions préjudicielles à la Cour de justice de l’Union européenne (CJUE) en interprétation des directives du 14 mai 1991 et du 22 mai 2001. Ces questions portaient principalement sur l’interprétation des dispositions de la directive de 1991, sur les composants du logiciel pouvant bénéficier de la protection juridique et sur le droit pour l’utilisateur d’observer, étudier ou tester le fonctionnement du logiciel.(3)

Dans l’arrêt du 2 mai 2012, la CJUE a ainsi été amenée à préciser les conditions et le champ d’application de la protection juridique des logiciels par le droit d’auteur.


1. Rappel du principe et des conditions de protection du logiciel par le droit d’auteur

La directive européenne du 14 mai 1991 sur la protection juridique des programmes d’ordinateur a consacré le principe de la protection des logiciels par le droit d’auteur. Cependant, le logiciel ne comprend pas que du code. Le logiciel est composé de plusieurs éléments, au titre desquels on retiendra notamment : les documents de conception, le langage de programmation, le code objet, le code source, les fonctionnalités, les interfaces, etc.

Dans l’affaire opposant SAS Institute à WPL, cette dernière avait régulièrement obtenu un exemplaire du logiciel SAS, dans sa version “learning edition” (version apprentissage). Le logiciel était soumis aux conditions de licence standard de SAS Institute. WPL n’a pas eu accès aux codes sources des composants, et n’a copié ni le code, ni tout ou partie des éléments de conception structurelle du code. SAS Institute reprochait à WPL (i) d’avoir indirectement copié les logiciels comprenant les composants SAS en violation de ses droits d’auteur sur ces composants, (ii) d’avoir utilisé une version du système SAS (la version apprentissage) en violation des conditions de la licence d’utilisation applicable et des droits d’auteur de SAS Institute, (iii) d’avoir copié les manuels du système SAS pour créer son propre manuel d’utilisation du logiciel World Programming System, sans autorisation de SAS Institute et en violation de ses droits.

    1.1 Les éléments du logiciel protégés par le droit d’auteur
La directive du 14 mai 1991 a consacré le principe de la protection du logiciel par le droit d’auteur, en tant qu’oeuvre littéraire. Comme pour toute autre oeuvre littéraire, la protection juridique du logiciel est acquise, sous réserve que celui-ci soit original.

La directive définit le terme “programme d’ordinateur” (ou logiciel) comme “les programmes sous quelque forme que ce soit, y compris ceux qui sont incorporés au matériel (…), les travaux préparatoires de conception aboutissant au développement d’un programme, à condition qu’ils soient de nature à permettre la réalisation d’un programme d’ordinateur à un stade ultérieur”.

En application des principes du droit d’auteur, la directive rappelle que seule “l’expression” du programme est protégée par le droit d’auteur, à l’exclusion des idées et principes qui sont à la base de la logique, des algorithmes et des langages de programmation. Ainsi, hormis les travaux préparatoires de conception, le code objet (ou programme exécutable) et le code source sont considérés comme étant l’expression du programme et bénéficient donc de la protection juridique.

    1.2 Les éléments exclus du champ de la protection par le droit d’auteur
L’arrêt SAS Institute permet de préciser les éléments du logiciel qui ne bénéficient pas de la protection juridique du droit d’auteur.

L’objet de la protection par le droit d’auteur est de réserver les droits sur les éléments d’expression  individuelle du logiciel ; l’originalité, condition de la protection, consiste en la personnalisation de l’oeuvre. En d’autres termes, la protection porte sur les éléments postérieurs au concept de départ, par lesquels l’auteur a matérialisé ou développé l’idée ou le concept, en le personnalisant (étape de mise en oeuvre du concept).

En revanche, les éléments à la base de l’oeuvre et de sa logique ne sont pas protégés par le droit d’auteur. En effet, le champ d’application du droit d’auteur permet à tous tiers, en partant d’une idée ou d’un concept, de le mettre en oeuvre en développant un logiciel similaire, voire identique, sous réserve de s’abstenir de copier le logiciel existant.

La Cour rappelle ainsi que les algorithmes, les procédures et méthodes de fonctionnement, le langage de programmation, mais également, les interfaces graphiques et les fichiers de données, dans la mesure où ces éléments ne permettent pas de reproduire le programme, ne constituent pas une forme d’expression du programme et ne sont pas protégés en tant que tels par le droit d’auteur.

De même, les fonctionnalités, le langage de programmation et le format de fichiers de données utilisés dans le cadre du programme pour exploiter certaines de ses fonctions ne constituent pas une forme d’expression du programme.

Plus précisément, le format de fichiers utilisés par un logiciel pour interpréter et exécuter les scripts des utilisateurs et pour lire et écrire des données dans un format de fichier de données spécifique constitue des éléments du programme au moyen desquels les utilisateurs ne font qu’exploiter certaines fonctionnalités du logiciel.

Ainsi, la Cour en conclut que le concept à la base d’un logiciel, les algorithmes, procédures et méthodes de fonctionnement, le langage de programmation, les interfaces graphiques et fichiers de données ne sont pas protégés par le droit d’auteur, en vertu de la directive de 1991.


2. L’exercice par l’auteur de ses droits exclusifs et ses limites

La protection du logiciel par le droit d’auteur signifie que le titulaire des droits dispose de droits exclusifs sur l’oeuvre, tels que visés aux articles 2 et 4 de la directive de 1991. Cependant, l’utilisateur légitime du logiciel dispose également de droits qui ne peuvent lui être refusés par le titulaire. Le litige opposant SAS Institute à WPL portait notamment sur les conditions d’exercice de ces droits.

    2.1 Les droits exclusifs de l’auteur et l’importance du contrat de licence
La directive de 1991, dans son article 4, réserve des droits exclusifs au bénéfice du titulaire des droits sur le logiciel, qui peut faire et autoriser (et a contrario, ne pas autoriser) (i) la reproduction permanente ou provisoire du programme d’ordinateur, (ii) la traduction, l’adaptation, l’arrangement et toute autre transformation du logiciel, ainsi que (iii) toute forme de distribution, y compris la location (la concession de licences d’utilisation) du logiciel.

Ces droits exclusifs appartenant au titulaire des droits peuvent ensuite être gérés contractuellement, dans la licence et/ou le contrat de maintenance, d’où l’importance du contrat de licence, de ses conditions et limitations.

    2.2 Les droits de l’utilisateur légitime du logiciel
En l’absence d’autorisation (contractuelle), l’utilisateur légitime d’un logiciel bénéficie néanmoins de droits dits résiduels, prévus aux articles 5 et 6 de la directive de 1991.

Les droits de l’utilisateur légitime comprennent :
    (i) le droit d’utiliser le logiciel d’une manière conforme à sa destination, y compris pour corriger les erreurs (au cas où aucun contrat de maintenance corrective ne serait prévu). Ce droit comprend la possibilité de reproduire le logiciel dans les limites techniquement nécessaires. Ainsi, le contrat de licence ne peut interdire les opérations de chargement et de déroulement nécessaires à l’utilisation du logiciel par son utilisateur légitime ;
    (ii) le droit de réaliser une copie de sauvegarde du logiciel ;
    (iii) la possibilité d’observer, d’étudier ou de tester le fonctionnement du logiciel, à condition que ces actes ne portent pas atteinte aux droits de l’auteur ;
    et enfin, (iv) le droit de décompiler le logiciel (que l’on désigne également ingéniérie inverse) pour obtenir les informations nécessaires à son interopérabilité. Ce dernier droit est cependant soumis aux conditions et limitations décrites à l’article 6 de la directive.

    2.3 L’exception d’observation, d’étude et de test du fonctionnement du logiciel
Le litige opposant SAS Institute à WPL portait notamment sur les conditions d’exercice de ces droits.

La High Court britannique a notamment demandé à la CJUE de se prononcer sur le fait de savoir si l’utilisateur légitime d’un logiciel pouvait utiliser le droit d’observer, d’étudier ou de tester le fonctionnement du logiciel dans un but dépassant le cadre du contrat de licence. SAS Institute soutenait en effet que WPL avait outrepassé ce droit dans la mesure où la licence applicable au logiciel SAS était accordée pour une utilisation non commerciale (version apprentissage ou formation). WPL aurait utilisé le logiciel à des fins sortant du champ de cette licence, l’exercice de son droit d’observer, d’étudier ou de tester le fonctionnement du logiciel portant atteinte aux droits du titulaire, SAS Institute.

La Cour rappelle que le titulaire des droits ne peut empêcher contractuellement que l’utilisateur légitime puisse déterminer les idées et les principes à la base des éléments du logiciel, lorsque cet utilisateur réalise les opérations autorisées en vertu de la licence, mais également les opérations de chargement et de déroulement nécessaires à l’utilisation du programme, sous réserve de ne pas porter atteinte aux droits de l’auteur.

En l’occurrence, pour la Cour, il n’y a pas d’atteinte aux droits de l’auteur lorsque l’utilisateur légitime n’a pas eu accès aux codes sources du logiciel, mais qu’il s’est limité à observer, étudier ou tester le logiciel. En l’espèce, WPL n’a pas eu accès au code source du logiciel SAS et n’a pas décompilé le code objet. WPL n’a fait que reproduire la fonctionnalité en utilisant le même langage de programmation et le même format de fichiers de données. En d’autres termes, WPL en qualité d’utilisateur légitime du logiciel SAS, a exercé son droit d’observation, d’étude et de test du logiciel et a développé un nouveau programme sur la base des mêmes idées et principes que le logiciel SAS, dans le cadre des droits accordés par la directive, sans porter atteinte aux droits de l’auteur.


En conclusion, on retiendra que l’arrêt SAS Institute est dans la lignée de la jurisprudence en matière de protection du logiciel par le droit d’auteur. Son intérêt réside dans la distinction entre les éléments du logiciel effectivement protégés par le droit d’auteur et les éléments non susceptibles de protection. A ce titre, la Cour a notamment déterminé que les fonctionnalités (dans la mesure où elles sont assimilables à une idée) et le langage de programmation n’étaient pas protégés par le droit d’auteur en vertu de la directive de 1991.

Le droit d’auteur ne s’oppose pas à la réexploitation d’une idée ou d’un concept par un tiers, sous réserve de ne pas reproduire l’oeuvre pré-existante. En conséquence, tout éditeur informatique peut développer un logiciel reprenant des fonctionnalités existantes dans des logiciels concurrents, dans le même langage de programmation, à condition de ne pas reproduire le code source (et le code objet) du premier logiciel. 

Il convient de noter cependant qu’un langage de programmation qui serait le résultat de la création intellectuelle de l’auteur est protégeable en vertu de la directive de 2001 sur la société de l’information (DADVSI).

Enfin, nous n’avons pas évoqué les questions relatives à la reproduction du manuel utilisateur par WPL, la Cour ayant là aussi appliqué les principes classiques du droit d’auteur. Le manuel utilisateur, dès lors qu’il s’agit d’une oeuvre originale, est protégé par le droit d’auteur et ne peut être librement reproduit par un tiers.

* * * * * * * * * * * *

(1) Directive 91/250/CEE du Conseil du 14 mai 1991 concernant la protection juridique des programmes d’ordinateur, transposée en droit français par la loi n°94-361 du 10 mai 1994 (voir articles L122-6 et s. du Code de la propriété intellectuelle) ; Directive du 22 mai 2001 sur l’harmonisation de certains aspects du droit d’auteur et des droits voisins dans la société de l’information, transposée en droit français par la loi n°2006-961 du 1er août 2006 (Loi DADVSI).

(2) Voir arrêt de la Cour de justice de l’Union européenne du 2 mai 2012, SAS Institute Inc. / World Programming Ltd

(3) Les questions préjudicielles concernent principalement l’interprétation à donner aux deux paragraphes suivants de la directive du 14 mai 1991: article 1er, 2é paragraphe “La protection prévue par la présente directive s'applique à toute forme d'expression d'un programme d'ordinateur. Les idées et principes qui sont à la base de quelque élément que ce soit d'un programme d'ordinateur, y compris ceux qui sont à la base de ses interfaces, ne sont pas protégés par le droit d'auteur en vertu de la présente directive” ; article 5, 3é paragraphe “La personne habilitée à utiliser une copie d'un programme d'ordinateur peut, sans l'autorisation du titulaire du droit, observer, étudier ou tester le fonctionnement de ce programme afin de déterminer les idées et les principes qui sont à la base de n'importe quel élément du programme, lorsqu'elle effectue toute opération de chargement, d'affichage, de passage, de transmission ou de stockage du programme d'ordinateur qu'elle est en droit d'effectuer.



Bénédicte DELEPORTE
Avocat

Deleporte Wentz Avocat
www.dwavocat.com

mai 2012

jeudi 24 mai 2012

Internet et handicap : les règles applicables face à la réalité du net

Le 6e Forum Européen de l’Accessibilité Numérique s’est tenu à Paris au mois de mars 2012. Intitulé “Placer l’accessibilité numérique au coeur des systèmes d’information”, les thèmes abordés couvraient des questions telles que Les enjeux industriels de l’accessibilité numérique, Concevoir pour tous, ou l’Edition numérique. Bien que pouvoirs publics et industriels reconnaissent le caractère primordial de la problématique de l’accessibilité pour tous aux technologies de l’information, le constat sur l’état de l’accessibilité du net reste très contrasté. 

L’accessibilité numérique (ou “e-accessibilité”) peut se définir comme l’accessibilité pour tous, personnes valides et personnes souffrant d’un handicap, aux sites internet et à leurs contenus, et de manière plus générale, à toute information sous format numérique, quels que soient le moyen d’accès et le mode de consultation. L’accès à internet et aux contenus numériques font désormais partie intégrante de notre vie quotidienne et sont devenus un droit fondamental au titre du droit à l'information. Le fait de ne pouvoir accéder à internet, pour des raisons techniques, économiques, mais également pour des raisons de handicap est un facteur de discrimination et d’exclusion sociale et professionnelle.

Cependant, bien que la question de l’accessibilité numérique soit au cœur des préoccupations des pouvoirs publics, la réalité de la mise en œuvre de ces principes reste très en-deçà des souhaits et engagements exprimés.


1. L’accessibilité numérique : des actions visant à favoriser l’accès de tous à internet et aux contenus numériques

Des initiatives tant publiques que privées ont permis l’élaboration de normes internationales dont le législateur français s’est inspiré pour instaurer une réglementation spécifique à l’accessibilité numérique.

    1.1 L’e-accessibilité : une volonté des instances internationales et européennes

Les standards internationaux  -  Fondé en 1994 avec le soutien de la Commission européenne, le consortium du World Wide Web (“W3C”) définit des spécifications communes pour l’internet et émet des recommandations ayant valeur de standards internationaux. Depuis 1997, un département du W3C, le WAI (Web Accessibility Initiative) travaille sur la question de l’accessibilité. Les recommandations du WAI, dénommées WCAG (ou Règles pour l’accessibilité des contenus Web), visent à assurer l’accessibilité des contenus web et proposent un ensemble de solutions permettant de développer des sites internet accessibles à tous. (1)

La Convention de l’ONU  -  La Convention de l'ONU du 13 décembre 2006 relative aux droits des personnes handicapées invite, dans son article 9 "Accessibilité", les Etats à prendre des mesures appropriées pour assurer et promouvoir l’accès des personnes handicapées aux systèmes et technologies de l’information et de la communication, y compris l’internet. (2)

Les publications des institutions européennes  -  Le Parlement, le Conseil, et la Commission ont publié entre 2002 et 2008 plusieurs résolutions, communications ou déclarations visant à (i) rendre obligatoire la mise en œuvre des mesure d'e-accessibilité aux sites web publics d’ici 2010, (ii) encourager les Etats membres à intensifier la promotion d’initiatives destinées à favoriser l’accès de tous aux technologies de l’information et des communications, en particulier les personnes handicapées et les personnes âgées et, (iii) adopter des normes européenne en matière d’e-accessibilité, sur la base des WCAG.

Parmi ces publication, on peut citer la résolution du Parlement européen de 2002 sur la communication de la Commission "eEurope 2002 : Accessibilité des sites web publics et de leur contenu", la résolution du Conseil de 2003 relative à la promotion de l'emploi et de l'intégration sociale des personnes handicapées et les communications de la Commission européenne de 2005 et 2008, portant sur l’e-accessiblité et intitulées "Vers une société de l’information accessible". (3)

La certification  -  Sur le plan de la certification, le label européen Euracert (European eAccessibility Certification) est attribué aux sites web conformes aux recommandations WCAG du W3C/WAI. Le contrôle de conformité est réalisé à la demande des exploitants de sites web, par rapport à des documents de référence sur l’accessibilité numérique des sites. Le label Euracert est attribué après que le site web en cause ait été labellisé par l’organisme partenaire du label Euracert dans le pays de l’exploitant du site. En France, l’organisme de labellisation en matière d’accessibilité numérique, partenaire d’Euracert est l’association BrailleNet qui a créé le label AccessiWeb. La liste des sites web labellisés AccessiNet est publiée sur le site. (3)

    1.2 L’e-accessibilité : une obligation légale pour les sites web du secteur public français

Afin de répondre aux exigences communautaires, le législateur français a adopté une série de textes venant définir et encadrer l’accessibilité numérique.

La loi du 21 juin 2004  -  La loi du 21 juin 2004 pour la confiance dans l’économie numérique (LCEN) dispose sous le titre 1er “De la liberté de communication en ligne”, en son article 3 que “L'Etat, les collectivités territoriales, les établissements publics et les personnes privées chargées d'une mission de service public veillent à ce que l'accès et l'usage des nouvelles technologies de l'information permettent à leurs agents et personnels handicapés d'exercer leurs missions.”

La loi du 11 février 2005  -  L’obligation d’accessibilité numérique des services publics a été instaurée par la loi du 11 février 2005 pour l’égalité des droits et des chances, la participation et la citoyenneté des personnes handicapées. Cette loi dispose que les services de communication en ligne développés par l'Etat, les collectivités territoriales et les établissements publics qui en dépendent, doivent être accessibles aux personnes handicapées. L'accessibilité concerne l'accès à tout type d'information sous forme numérique quels que soient le moyen d'accès, les contenus et le mode de consultation et les recommandations internationales pour l'accessibilité de l'internet doivent être appliquées.

Le décret du 14 mai 2009  -  Le décret du 14 mai 2009 est venu fixer les règles relatives à l'accessibilité numérique, à savoir :
    - des règles techniques, sémantiques, organisationnelles et d'ergonomie à mettre en oeuvre par les services de communication publique en ligne des administrations, permettant aux personnes handicapées de réceptionner et comprendre les informations diffusées, d'utiliser ces services et, le cas échéant, d'interagir avec ces derniers. Ces règles constituent le "référentiel d'accessibilité". L’autorité administrative compétente doit attester, par le biais d’une déclaration de conformité, que ses services de communication en ligne sont conformes au référentiel d’accessibilité ;
    - une formation du personnel des administrations portant sur l’accessibilité numérique et sur la conformité aux règles et standards nationaux et internationaux ;
    - des délais de mise en conformité des sites existants de deux ans pour les services de l’Etat (et établissements publics qui en dépendent) et trois ans pour les collectivités territoriales (et établissements publics qui en dépendent), à compter de la publication du décret. A défaut de conformité dans les délais, le ministre chargé des personnes handicapées peut mettre en demeure l’autorité administrative compétente de se conformer au référentiel d’accessibilité dans un délai ne pouvant excéder six mois, au-delà duquel le service sera inscrit sur une liste de services non conformes.

L'arrêté du 21 octobre 2009  -  Cet arrêté, portant sur le référentiel général d’accessibilité pour les administrations (RGAA), précise les exigences techniques à respecter par les autorités administratives. Le RGAA est un recueil de règles et de bonnes pratiques qui visent à améliorer l’e-accessibilité des sites web des administrations. Il se fonde sur les normes et standards en vigueur, en particulier sur le standard international WCAG 2.0. (5)

Concrètement, l'e-accessibilitié consiste, pour un site web, à intégrer des fonctionnalités permettant notamment d'agrandir la taille des caractères des textes, ou la possibilité d'accéder à la version audio des contenus.

En dépit d’un tel dispositif légal, force est de constater que la mise en œuvre des standards de l’accessibilité numérique reste encore très limitée sur le web français.


2. L’accessibilité numérique pour tous : un constat mitigé


En France, l’accessibilité numérique peine à se développer et ce pour plusieurs raisons.

    2.1 La question de l’accessibilité des sites web du secteur privé
L’une des premières raisons de la lenteur des sites web français à déployer des techniques améliorant leur e-accessibilité tient au fait que la réglementation relative à l'obligation d'accessibilité numérique ne s'impose pas aux sites web du secteur privé. Les textes réglementaires cités plus haut concernent le secteur public.

L'obligation d’e-accessibilité pour les sites du secteur privé n’est mentionnée ni par les textes internationaux, ni par les textes européens. Les instances européennes, dans le cadre d’une résolution du Parlement de 2002 et d'une communication de la Commission de 2008, prévoient seulement, d’une part de parvenir à l’accessibilité des sites web privés, en commençant par les sites qui bénéficient d’un financement public, "dès que possible", et d’autre part d’encourager "les prestataires de services non publics, en particulier les propriétaires de sites web fournissant des services d'intérêt général et les fournisseurs de sites web commerciaux (…)" à améliorer l'accessibilité du web.

On peut regretter que les exploitants des sites web du secteur privé, notamment les grands sites de e-commerce, ne déploient pas les fonctionnalités améliorant l’accessibilité de leurs services en ligne. Ainsi, parmi les sites labellisés AccessiWeb, on ne trouve que quelques sites du secteur privé, tels que Carrefour, Axa ou Groupama par exemple.

    2.2 Les sites web du secteur public ne donnent pas l'exemple
Malgré la réglementation applicable en France, les sites du secteur public français ne donnent pas l’exemple de la mise en oeuvre de l’accessibilité numérique. Ainsi, le décret du 14 mai 2009 est entré en application depuis trois ans. Les délais de mise en conformité à l'accessibilité numérique des sites du secteur public sont arrivés à échéance depuis un an pour les services de communications en ligne de l’Etat ; le délai de trois ans pour les collectivités territoriales expirant ces jours-ci.

Bien que les délais de mise en conformité des sites web du secteur public aient expiré, plusieurs études montrent que la grande majorité de ces sites demeurent, en pratique, inaccessibles pour les handicapés. Ce constat est notamment dressé par le collectif citoyen "Article 47", qui a publié, le 1er février 2011, une Lettre ouverte pour l’accessibilité numérique des services publics adressée aux ministres concernés. Dans cette lettre, le collectif demandait l’application effective de l’article 47 de la loi du 11 février 2005, visant à rendre les sites web des services publics accessibles aux personnes handicapées.

Selon le collectif, les sites internet conformes au Référentiel général d’accessibilité pour les  administrations (RGAA) restent des exceptions dans le paysage web des services publics français. Seulement quelques éditeurs de sites publics se sont saisis de la question et ont mis les sites web en conformité avec les exigences du référentiel d’accessibilité.

Parmi les sites e-accessibles, on notera par exemple, au niveau des sites gouvernementaux le site service-public.fr (www.service-public.fr), pour les collectivités locales le site du Conseil général de Loire-Atlantique (www.loire-atlantique.fr) ou le site de la ville de Saint-Maur des Fossés (www.saint-maur.com), pour les entreprises publiques, le site TER SNCF (www.ter-sncf.com).

    2.3 Les freins au développement de l’e-accessibilité
Comment expliquer que les sites web conformes aux règles de l’e-accessibilité restent si peu nombreux en 2012 ? Quels sont les freins au développement de l’e-accessibilité ?

Les outils techniques  -  La technologie du logiciel a évolué ces dernières années et propose des outils permettant une utilisation différente de la technologie numérique. Outre la fonctionnalité permettant de modifier la taille des caractères des textes ou la taille de l’écran d’un site web, le marché du logiciel propose depuis plusieurs années des systèmes de reconnaissance vocale (intégré dans Windows Vista notamment) permettant d’utiliser un ordinateur sans contact tactile, ou de lecteur d’écran (par exemple VoiceOver dans MacOS et iOS) permettant aux malvoyants d’utiliser un ordinateur.

La formation des développeurs web  -  Les programmes de formation au développement web n’intègrent pas systématiquement de module de formation technique à l’e-accessibilité des sites web. Les développeurs n’ont donc pas le réflexe, dès la conception des sites pour le secteur privé ou le secteur public, d’intégrer une approche d’e-accessibilité en proposant la modulation de la taille des textes, une version audio des contenus, etc.

Une réglementation peu claire  -  Le collectif du l’article 47 souligne que la réglementation “souffre d’un problème de lisibilité”, notamment concernant le périmètre de son application et des dérogations.

En outre, la certification des sites web est une procédure volontaire et non obligatoire. Il est même possible de s’auto-déclarer conforme aux recommandations, sans contrôle d’un organisme tiers.

L’ignorance ou la sous-estimation de l’importance de l’e-accessibilité  -  Enfin, la question de l’accessibilité numérique reste encore ignorée ou sous-estimée par un grand nombre d’entreprises qui ont encore du mal à percevoir que l'accessibilité et plus généralement, la prise en compte de la diversité, devraient constituer un élément important de leur stratégie commerciale. 


A une époque où les questions liées aux discriminations et à la protection des libertés fondamentales restent sensibles, la reconnaissance du droit des handicapés à l’accès aux technologies de l’information, mais également de toute personne physiquement diminuée par la maladie ou par l’âge, demeure un véritable enjeu de société.

Enfin, au-delà de la “simple” accessibilité à internet se pose la question de l’évolution des technologies de l’information. Qu’en est-il de la “mobile e-accessibilité” si l’on étend le périmètre d’application aux smartphones et aux tablettes ?

* * * * * * * * * * *

(1) Le site web du consortium W3C est accessible à l’URL: http://www.w3.org/

(2) La Convention de l’ONU relative aux droits des personnes handicapées, adoptée le 13 décembre 2006 est entrée en vigueur le 3 mai 2008. L’article 9 “Accessibilité” dispose : “Afin de permettre aux personnes handicapées de vivre de façon indépendante et de participer pleinement à tous les aspects de la vie, les États Parties prennent des mesures appropriées pour leur assurer, sur la base de l’égalité avec les autres, l’accès (…) aux systèmes et technologies de l’information et de la communication. (…) Les États Parties prennent également des mesures appropriées pour : (…) Promouvoir l’accès des personnes handicapées aux nouveaux systèmes et technologies de l’information et de la communication, y compris l’internet;”.

(3) Résolution du Parlement européen du 13 juin 2002 sur la communication de la Commission « eEurope 2002 : Accessibilité des sites web publics et de leur contenu » (COM (2001)529-C-5-0074/2002-2002/2032(COS)) ; Résolution du Conseil du 15 juillet 2003 relative à la promotion de l'emploi et de l'intégration sociale des personnes handicapées (2003/C175/01) ; Communication de la Commission européenne, du 13 septembre 2005, sur « l’e-accessiblité » (COM (2005)425) ; Communiqué de presse du 12/06/2006 : « L’internet pour tous : les ministres européens s’engagent en faveur d’une société de l’information accessible fondée sur l’inclusion » : déclaration de Riga (Lettonie), dans laquelle les ministres européens fixent comme objectif une accessibilité totale des sites web publics en 2010 ; Communiqué de presse de la Commission européenne du 2 juillet 2008 informant du lancement d’une consultation publique portant sur les actions des Etats membres permettant d’améliorer l’accessibilité aux sites web ;  Communication de la Commission européenne du 1er déc. 2008 :”Vers une société de l’information accessible”, (COM (2008)804 final).

(4) Les sites Euracert et AccessiWeb sont accessibles à : http://www.euracert.org/fr/ et http://www.accessiweb.org/

(5) Voir Loi n°2004-575 du 21 juin 2004 pour la confiance dans l’économie numérique ; Loi n°2005-102 du 11 février 2005 pour l’égalité des droits et des chances, la participation et la citoyenneté des personnes handicapées, notamment article 47 ; Décret n°2009-546 du 14 mai 2009 pris en application de l’article 47 de la loi n° 2005-102 du 11 février 2005 sur l'égalité des droits et des chances, la participation et la citoyenneté des personnes handicapées et créant un référentiel d'accessibilité des services de communication publique en ligne ; Arrêté du 21 octobre 2009 relatif au référentiel général d'accessibilité pour les administrations (RGAA) (NOR: BCFJ0917114A) et enfin, voir le site internet : www.references.modernisation.gouv.fr




Bénédicte DELEPORTE - Avocat
Betty SFEZ - Avocat

Deleporte Wentz Avocat
www.dwavocat.com

Mai 2012

samedi 24 mars 2012

L'hébergement de données de santé en Cloud soumis à des contraintes juridiques particulières

Les professionnels de santé (médecins exerçant en cabinet, en clinique ou dans un établissement de santé publique, pharmaciens, etc.) collectent une multitude de données à caractère personnel dans le cadre de leur activité, concernant le patient et sa santé. Ces informations apparaissent, entre autres, dans le dossier médical du patient, les résultats d'examen, les comptes rendus d'hospitalisation.

Le recours à un prestataire informatique pour le stockage et la conservation des données est devenu une pratique courante, y compris en mode Cloud, le cloud computing permettant notamment une gestion des données simplifiée (accessibilité, flexibilité, portabilité, etc.) et une réduction des coûts (investissements en matériel et logiciel réduits et facturation à l'usage).

Toutefois, professionnels de santé et prestataires Cloud doivent être vigilants : d'une part, le recours à un tiers pour héberger des données de santé ne décharge pas le professionnel de santé de ses obligations légales en matière de collecte et de traitement des données ; d'autre part, la fourniture de services d'hébergement de données de santé est soumise à un certain nombre de conditions.


1. Le professionnel de santé : responsable de traitement des données hébergées

On entend généralement par “donnée de santé” les informations relatives à l'état de santé (tant physique que psychique) d'un patient, recueillies ou produites à l'occasion des activités de prévention, de diagnostic ou de soins du patient. Il s’agit de données à caractère personnel, dont la collecte et le traitement sont régis par les dispositions de la loi Informatique et Libertés, complétée en l’espèce par le Code de la santé publique (CSP).(1)

    1.1 Les obligations spécifiques en matière de collecte et de traitement de données de santé
 
Les données de santé sont considérées comme des données sensibles, dont le traitement est en principe interdit, sauf exceptions. Les exceptions sont en réalité assez nombreuses puisqu’elles comprennent notamment, outre la plupart des traitements pour lesquels la personne concernée a donné son consentement exprès, les traitements nécessaires aux fins de la médecine préventive, des diagnostics médicaux, de l’administration de soins ou de traitements, ou de la gestion de services de santé et mis en oeuvre par un membre d’une profession de santé.(2)

Les traitements de données comprennent tous types d'opérations qui permettent d'identifier une personne physique, directement ou indirectement, et notamment, le fait de collecter, enregistrer, conserver (et donc héberger), modifier, diffuser, détruire des données.

Les formalités préalables à la collecte de données de santé :
Selon le type de traitement envisagé, le professionnel de santé doit soit déclarer à la CNIL, soit obtenir son autorisation, préalablement à la mise en oeuvre du traitement de données. Les formalités (déclaration ou demande d'autorisation), varient en fonction du traitement concerné (ex: gestion des laboratoires d'analyses, traitements relatifs au dossier médical partagé, etc.).

Les obligations du responsable de traitement :
En matière de données de santé, le responsable de traitement est en principe le médecin exerçant à titre libéral, le dirigeant d'une clinique ou le chef de service de l'établissement de santé public en charge des traitements de données.

En qualité de responsable de traitement, le professionnel de santé est tenu de respecter plusieurs obligations. En cas de manquement à la loi, le responsable de traitement engage sa responsabilité. Ces obligations restent à sa charge, même en cas de recours à la sous-traitance pour l'hébergement des données. Il répond ainsi des manquements à la loi et des failles de sécurité causés par le prestataire Cloud. Le professionnel de santé doit notamment :

- Garantir la sécurité et la confidentialité des données : les données de santé sont soumises à un haut niveau de sécurité. Le Code de la santé publique impose au professionnel de santé le respect de référentiels de sécurité. En pratique, il doit prendre toutes précautions utiles pour empêcher que les données ne soient modifiées, effacées par erreur, ou que des tiers non autorisés aient accès au traitement. Il est donc tenu de mettre en oeuvre, au sein de son établissement de santé, des mesures de sécurité physique (telles que l’accès contrôlé aux locaux hébergeant les serveurs et/ou une liste des personnes autorisées à accéder aux données) et techniques (telles que serveurs sécurisés, utilisation de la carte de professionnel de santé pour accéder aux données). En cas d’hébergement par un tiers, il devra s'assurer que le prestataire Cloud met en oeuvre des mesures de sécurité suffisantes.

- Obtenir le consentement des patients concernés, les informer et garantir leurs droits : le consentement des patients pour la collecte et l'hébergement informatisé de données de santé doit être recueilli. Ce type de traitement ne peut être réalisé à leur insu, sauf exceptions.(3) En outre, le professionnel de santé doit : (i) informer le patient de l'identité des destinataires des données et, le cas échéant, des éventuels transferts de données hors Union européenne, et (ii) assurer le respect des droits des patients concernés, à savoir les droits d'accès, de rectification (mise à jour), de contestation et d'opposition (suppression/désinscription) au traitement de leurs données.

    1.2 Les sanctions encourues en cas de non-respect des obligations en matière de collecte et de traitement de données
En cas de manquement à ses obligations légales, le professionnel de santé encourt les sanctions suivantes :

- Sanctions administratives : en cas de manquement constaté à la suite d'un contrôle sur place, la CNIL peut prononcer un avertissement, une mise en demeure de faire cesser le manquement constaté dans un certain délai, ou si le professionnel de santé ne se conforme pas à la mise en demeure, une sanction pécuniaire d'un montant maximum de 300.000€, une injonction de cesser le traitement ou, le cas échéant un retrait de l’autorisation accordée par la CNIL.(4)

- Sanctions pénales : est puni d’un an d'emprisonnement et 15.000€ d'amende, le fait d'obtenir ou de tenter d'obtenir la communication de données de santé sans le consentement du patient concerné. Sont notamment punis de 5 ans d’emprisonnement et 300.000€ d’amende :
    - tout acte de cession à titre onéreux de données de santé identifiantes, directement ou indirectement, y compris avec l'accord du patient concerné ;
   - le fait de procéder à un traitement de données : (i) y compris par négligence, sans respecter les formalités préalables ; (ii) malgré l'opposition du patient concerné ; (iii) sans prendre les mesures de sécurité prescrites par la loi et (iv) sans le consentement exprès du patient concerné.


2. Le prestataire Cloud de données de santé à caractère personnel : des services d'hébergement soumis à conditions


L'activité d'hébergement de données de santé en Cloud nécessite, pour le prestataire, de respecter un certain nombre de conditions spécifiques.(5)

    2.1 La nécessité d'un agrément pour l’hébergement de données de santé à caractère personnel
Le prestataire d'hébergement de données de santé à caractère personnel doit obtenir un agrément pour exercer son activité. Cet agrément est délivré par le ministre chargé de la santé, qui se prononce après avis de la CNIL et d'un comité d'agrément des hébergeurs. L’agrément est valable pour une durée de 3 ans, renouvelable. A ce jour, 32 sociétés ou organismes ont obtenu l’agrément, soit pour l’hébergement des traitements de données de santé de leurs patients, soit pour l’hébergement de données de santé (dossier médical partagé ou dossier médical personnel) des patients d’organismes tiers.

L'obtention de l’agrément est soumise à la mise en oeuvre (i) de solutions techniques, d'une organisation et de procédures de contrôle assurant la sécurité, la protection, la conservation et la restitution des données hébergées et (ii) d'une politique de confidentialité et de sécurité. L'hébergeur doit ainsi démontrer sa capacité à assurer la confidentialité, la sécurité, l'intégrité et la disponibilité des données de santé qui lui seront confiées par les professionnels de santé.(6)

    2.2 Des engagements contractuels précis adaptés aux contraintes des professionnels de santé
Le prestataire Cloud de données de santé devra proposer un service adapté aux contraintes spécifiques des professionnels de santé, compte tenu notamment de la nature des informations hébergées, de leur niveau de confidentialité, de leur volume, etc. Que le professionnel opte pour un hébergement en Cloud public (ressources mutualisées, la plateforme cloud peut donc être partagée entre plusieurs utilisateurs), privé (infrastructure fermée, dédiée à l'utilisateur), ou hybride (permettant la communication entre les deux infrastructures), les engagements du prestataire devront être contractualisés.

Le Code de la santé publique (art. L1111-8) exige que la prestation de service d'hébergement  conclue avec un professionnel de santé fasse l'objet d'un contrat écrit comprenant a minima, les éléments suivants :
- la description des prestations couvertes par le contrat et des moyens mis en oeuvre par l'hébergeur pour la fourniture des services ;
- les modalités de mise à disposition des données, ainsi que la description des conditions de recueil de l'accord des patients concernés par ces données s'agissant tant de leur hébergement que de leurs modalités d'accès et de transmission. Seuls pourront accéder aux données hébergées les patients concernés et les professionnels de santé qui les prennent en charge ;
- la mention des indicateurs de qualité et de performance permettant la vérification du niveau de service annoncé (convention de performance ou Service Level Agreement) ;
- une information sur les garanties permettant de couvrir la défaillance éventuelle de la plateforme  par la mise en oeuvre, par exemple, d’une solution de redondance (duplication de l’infrastructure) afin de permettre la continuité de service sans interruption en cas de chute de l’infrastructure principale en routant le service vers l’infrastructure secondaire ;
- une clause de réversibilité relative à la restitution au professionnel de santé de l'ensemble des données externalisées, au terme du contrat.

En sus de ces informations, il conviendra de préciser au contrat : les mesures de sécurité mises en oeuvre (systèmes de traçabilité des accès, chiffrement des données), la répartition des responsabilités entre le professionnel de santé et le prestataire, et la localisation des centres serveurs.

En matière de cloud computing, il est en effet fréquent que les données circulent entre des centres serveurs situés dans des pays différents. Ces transferts, même s’ils sont transparents pour l’utilisateur, restent soumis aux dispositions de la loi Informatique et Libertés. Les transferts de données depuis le territoire européen vers des pays situés en dehors de l'Union européenne sont interdits, sauf vers un pays reconnu comme offrant un niveau de protection adéquat. En cas de recours à un service Cloud, le professionnel de santé, responsable de traitement, devra s’informer sur la localisation des centres serveurs auprès du prestataire, et en cas de transfert hors Union européenne, procéder aux formalités auprès de la CNIL, préalablement à la mise en oeuvre du service.


Il appartient donc tant au professionnel de santé qu'au prestataire Cloud de prendre des précautions suffisantes quant au traitement des données de santé : le professionnel de santé en communiquant ses contraintes d’utilisation du service au prestataire et en s’informant auprès de celui-ci sur la teneur des prestations et du contrat préalablement à sa conclusion, et le prestataire en faisant jouer son obligation de conseil auprès du professionnel de santé.

Les contraintes réglementaires dans le domaine des données de santé à caractère personnel étant particulièrement strictes, tout manquement à ses obligations par l’une ou l’autre des parties est soumise soit à des sanctions administratives, soit à des sanctions pénales, sans oublier la mise en oeuvre de la responsabilité contractuelle et l’impact négatif fort de ces manquements sur la réputation du professionnel de santé et/ou sur le prestataire de service Cloud. En atteste par exemple l'avertissement récemment prononcé par la CNIL à l'encontre d'un hébergeur de données de santé, ayant fait une déclaration mensongère dans son dossier de demande d'agrément. Celui-ci prétendait chiffrer les données médicales hébergées, ce qui était inexact.(7)

* * * * * * * * * * * *

(1) Loi n°78-17 du 6 janvier 1978 relative à l'informatique, aux fichiers et aux libertés modifiée ; Loi n° 2002-303 du 4 mars 2002 relative aux droits des malades et à la qualité du système de soins (dite “Loi Kouchner”) ; Articles L.1110-4, L.1111-7, L.1111-8, R.1110-1, R.1111-1 et suivants du Code de la santé publique ; Articles 226-16 et suivants du Code pénal.
(2) Sur les données de santé, voir l’article 8 de la loi Informatique et Libertés.
(3) En cas d'hébergement, ce consentement n'est pas exigé dès lors que l'accès aux données détenues n'est pas partagé mais limité au professionnel ou à l'établissement de santé qui les a déposées, ainsi qu'au patient concerné.
(4) La CNIL dispose du pouvoir de réaliser des contrôles sur place de conformité à la loi Informatique et Libertés auprès des responsables de traitement. Ainsi, les agents de la CNIL peuvent, sur décision de son Président, accéder aux locaux des cabinets médicaux et autres établissements de santé, demander communication de tout document nécessaire et en prendre copie, recueillir tout renseignement utile, accéder aux programmes informatiques et aux données. L’objectif est d’obtenir un maximum d’informations, techniques et juridiques, pour apprécier les conditions dans lesquelles sont mis en œuvre les traitements de données personnelles. Depuis quelques années, les contrôles de la CNIL auprès des professionnels de la santé se sont intensifiés.
(5) Voir les articles L.1111-8 et R.1111-9 à 1111-15 du CSP.
(6) Les conditions de l’agrément et la liste des hébergeurs agréés sont accessibles sur le site web de l'Agence des Systèmes d'Informations Partagés de Santé (ASIP santé: http://esante.gouv.fr/).
(7) Voir communiqué CNIL du 9 janvier 2012 : "La CNIL sanctionne une déclaration mensongère d'un hébergeur de données de santé". En 2009, une société avait déclaré dans son dossier de demande d’agrément qu'elle chiffrait l'ensemble des données médicales hébergées, par un procédé dit de "chiffrage fort", et a obtenu l'agrément. Début 2011, lors d’un contrôle de la CNIL, celle-ci a constaté que les données médicales n'étaient pas chiffrées et qu'elles étaient accessibles aux administrateurs informatiques de l’hébergeur et non pas exclusivement au personnel de santé habilité (la société avait uniquement protégé certaines des données de santé par un codage créé en interne). La CNIL a considéré que le traitement de données était contraire à loi Informatique et Libertés et au Code de la santé publique qui impose de prévenir le Ministre de la santé de tout changement affectant les informations fournies lors de la candidature. En prétendant chiffrer toutes les données médicales, ce qui était inexact, et en n'informant pas le Ministre de la santé d'un tel changement de procédure, l’hébergeur n'avait pas respecté le Code de la santé publique et traitait donc les données de manière illicite.


Bénédicte DELEPORTE – Avocat
Betty SFEZ – Avocat

Deleporte Wentz Avocat
www.dwavocat.com

Mars 2012