Le Conseil d’Etat a rappelé les principes de base, même en matière de sanction administrative on doit tenir compte du principe de proportionnalité et de personnalisation.



A mon avis la CNIL devrait faire un effort de motivation dans ses décisions, notamment en abandonnant sa formule perpétuelle où elle indique que sanctionner est nécessaire pour informer la population sur la réglementation en matière de protection des données, dans le genre critère totalement extérieur à la personne condamnée on fait pas mieux…



Finalement, l’aspect le plus intéressant de la décision du Conseil d’Etat est sur le fait qu’il est confirmé que le passage préalable par la mise en demeure n’est pas obligatoire (chose qui me semblait plus faire de doute, mais qui est souvent soulevée).



         En revanche, on peut faire un premier bilan s’agissant de la série de condamnations de responsables du traitement par la CNIL pour la même “faille” (on est plus sur un problème de conception à mon sens).



En effet, et j’ignore si c’est le cas s’agissant d’optical, mais je sais en revanche que pour d’autres sanctions c’est un même outil qui serait systématiquement en cause, l’éditeur facturerait même la mise à jour consistant à vérifier que les infos affichées correspondent au compte client (probablement la gestion des sessions et token qui va bien).



Aussi, cet outil serait identifié comme mal conçu au départ et vendu à des grandes entreprises. Néanmoins, depuis les sanctions de la CNIL, l’éditeur n’aurait jamais eu de compte à rendre et ferait payer sa mise à jour sous prétexte de conformité RGPD ?!?



Est-ce que les notions de responsable du traitement et de sous-traitant ne montreraient pas leurs limites, là où en réalité il s’agit d’une problématique d’éditeur, et avec elles la jurisprudence de la CNIL qui consiste à ne pas faire de distinguo entre le responsable du traitement et sous-traitant ayant ou devant avoir des compétences informatiques et ceux qui n’ont d’autre solution que de se fier à un professionnel vendant un logiciel sur l’étagère ?



Prétendre qu’il faut faire de la “security by design” (j’ai envie de fumer ceux qui utilisent cette formule, mais c’est pas le sujet…) et passer totalement à coté de l’éditeur de logiciel s’agissant du RGPD et de la protection des données à caractère personnel, n’est-il pas la démonstration d’une erreur de conception originelle de la règlementation ?



Peut-on rattraper cette énorme erreur en passant par le défaut d’information et de conseil de l’éditeur et donc en sortant totalement de la règlementation sur la protection des données, qui à nouveau démontre son inefficacité ?



Vous avez 2 heures ! " />

Mihashi a écrit :



.

Si le sous-traitant manipule les données, alors c’est un partage de la responsabilité (plutôt que du « risque » " />).





Non, aucun rapport, par définition le sous traitant “manipule” des données pour le compte du responsable du traitement sinon il n’est pas sous traitant.



En revanche pour qu’il existe une coresponsabilité il faut qu’il y ait une codétermination des finalités, dans ce cas il s’agit de coresponsables du traitement (une des nouveautés du RGPD)

Soriatane a écrit :



Je ne comprends pas.

Si tu te fais condamner par la CNIL tu peux te retourner contre l’éditeur qui t’a fournit un logiciel troué qui a fait défaut alors que tu suivais leurs recommandations de configuration, non?





En principe non, t’as responsabilité est personnelle s’agissant de la réglementation sur la protection des données à caractère personnelle, un peu comme au pénal.



Sauf qu’au pénal on fait (en principe) intervenir l’élément moral (l’intention) pour dire constituer ou non une infraction, ceci t’empêchant d’être condamné pénalement par la faute d’un tiers.



A l’inverse le manquement permettant la sanction administrative par la CNIL se contente de la simple matérialité des faits indifféremment de ton intention, donc tu peux te faire fumer pour les manquements d’un tiers alors que précisément tu as cru pouvoir te fier à ce tiers professionnel.



Par ailleurs, ce tiers ne doit pas pour autant endosser ta sanction administrative mais éventuellement des dommages et intérêts pour sa faute dans vos rapports contractuels (dommages qui ne peuvent recouvrir l’amende prononcée, c’est le même mécanisme qui par exemple interdit l’assurance pénale).

Zerdligham a écrit :



Rédiger le contrat en obligation de résultat, pas de moyen. Si le cahier de charges dit que les fiches personnelles ne sont accessibles qu’aux personnes concernées, osef que le dev ait été fait dans les règles de l’art ou pas, si elles sont accessibles à d’autres, le contrat est violé.

Le cas foireux est selon moi plutôt si la faille est dans la conjonction d’erreurs de dev et d’install/paramétrage, où il peut y avoir zoophilie sur diptères pour savoir qui est responsable de quoi.





Néanmoins, le manquement à l’obligation de résultat si tu veux le faire trancher par une Juridiction, je te recommande fortement l’intervention d’un expert.



A l’inverse, en face et si tu viens par exemple avec juste un constat d’huissier de la reproduction de la faille, je vais te dire que tu n’as pas correctement configuré mon soft ou le serveur qui l’héberge et que la faille constatée par huissier est de ton fait non de mon programme.

Zerdligham a écrit :

• les charges passées en analyse et traitement du dossier + une évaluation du préjudice en image + des pénalités forfaitaires
  
  (selon comment est rédigé le contrat et comment est traitée l’affaire, à mon avis en pratique ça se réglerait plus souvent par une négo en backoffice que par une action en justice)
  
  
  
  
  
  Sauf que si tu n’as aucune exploitation de la faille ou plus exactement que tu n’arrives pas à le démontrer et donc que cela a eu des conséquences dommageables, il n’y aura aucun intérêt à l’action. Un peu comme en matière de construction, un simple non respect d’une norme n’est pas en lui-même indemnisable si par ailleurs cela n’a aucun effet dommageable, d’où la nécessité de toujours démontrer l’existence du dommage.

Soriatane a écrit :



Je pense surtout que le sous-traitant doit démontrer que l’intrusion n’est pas réalisale. Charge au donneur de s’en assurer et de se retourner contre prestataire.

Il faut éviter les donneurs d’ordre qui joue au ykafoq et se décharge sur les sous-traitants, leur demandant l’impossible.





Attention, éditeur de logiciel != sous-traitant:

. l’éditeur développe un logiciel, qui peut être sur étagère ou sur-mesure, il ne traite pas les données du responsable du traitement.

. le sous-traitant est celui qui traite pour le compte du responsable du traitement des données à caractère personnel, ce dernier définissant les finalités du traitement.

. tu as encore celui qui a le cul entre deux chaises, à savoir l’éditeur offrant une prestation de maintenance, sa prestation n’est pas de manipuler les données pour en tirer quelque chose, néanmoins il y accède ou peut y accéder dans le cadre des mises à jour ou des sauvegardes, du coup avec la réglementation actuelle il se prend sur le coin du nez toutes les obligations d’un sous-traitant alors qu’à mon avis sa situation est différente de celui qui exploite vraiment les données.



Ainsi, lorsque tu achètes un windows ou une suite office (sauf cloud) microsoft n’est pas ton sous-traitant, mais simplement un éditeur ne relevant pas des obligations du RGPD.



C’est le sens de mon propos; on demande à des responsables du traitement sans considération de leurs compétences du juger du degré de sécurisation des logiciels qu’ils utilisent, alors que le concepteur d’un logiciel doit être dans 90% des cas un tiers au responsable du traitement et qui n’accèdera jamais aux données personnelles que son logiciel traitera.



En prétendant à la “security by design” tout en laissant de coté la responsabilité de l’éditeur, la règlementation sur la protection des données à caractère personnel fait l’impasse sur un point essentiel.



Après on peut même élargir le débat, si la CNIL est dans sa mission lorsqu’elle sanctionne le non respect des droits des personnes concernées par un traitement, est-ce bien le cas lorsqu’elle sanctionne des failles de sécurité sans fuite démontrée ? Dans ce dernier cas, si la CNIL sanctionne, elle interdit au passage et de facto des poursuites au pénal du fait du principe non bis in idem (bien longtemps on prétendait que l’on pouvait faire les deux si on dépassait pas le quantum de la peine, la CEDH a clairement indiqué que non s’agissant de l’AMF, ce qui est totalement transposable à la CNIL).

Zerdligham a écrit :



Au doigt mouillé et en cinq minutes, je dirais:

Le principe de personnalisation de la peine est justement ce qui permettra à la CNIL de sanctionner plus sévèrement un groupe qui aurait du avoir les moyens d’auditer l’outil que le plombier du quartier.





On est d’accord, mais pourquoi alors ne pas clairement le relever dans la motivation, telles que rédigées aujourd’hui ses décision ne font jamais état de la puissance de feu de la boite visée ou de sa compétence (à l’exception notable de google).







Zerdligham a écrit :



Par contre pour moi c’est bien au responsable de traitement d’être coupable par défaut. L’implication des sous-traitants / éditeurs, doit être gérée au niveau contractuel.

Pour prendre un exemple caricatural, si je fournis un stockage en ligne sans aucune protetion et qu’un client y fout des données perso, je ne suis coupable que si je lui ai promis que mon système protégeait par défaut les données qu’il y mettait.

Le cas de la faille est moins tranché, mais répond selon moi de la même logique. En l’absence d’engagement formel de l’éditeur sur la qualité du logiciel, il n’a pas à répondre des utilisations qui sont faites de son logiciel.





En fait comme je le suggère dans mon premier post, on peut effectivement tenter de se retourner contre l’éditeur qui commet une négligence (ici grossière) sur le terrain de la faute contractuel.



Néanmoins, cela va se traduire par à minima une expertise judiciaire pour objectivement établir comment fonctionne le logiciel et constater une programmation “non conforme aux règles de l’art” (pour reprendre la formule consacrée), à charge néanmoins que le dit expert soit effectivement compétent…



Ceci fait, il va falloir démontrer le préjudice causé par la négligence qui ne peut être celui de l’amende prononcée par la CNIL. Donc souvent rien sauf à démontrer que la faille s’est doublée d’exploitations dommageables.



Donc la procédure sera très aléatoire s’agissant de son résultat, surtout l’éditeur négligeant ne sera pas condamné au titre de la réglementation sur la protection des données à caractère personnel, mais bien sur le droit commun des contrats.



Par conséquent, si comme toi j’estime que le responsable du traitement doit pouvoir voir sa responsabilité engagée (tout comme le sous-traitant), avoir totalement zappé l’éditeur me semble un énorme trou dans la raquette du RGPD & co à partir du moment où un logiciel est conçu pour accueillir des données à caractère personnel.

Mihashi a écrit :



L’éditeur ne manipule pas de données personnelles, il ne peut donc pas être tenu comme responsable d’une mauvaise manipulation de données personnelles…





Oui cf. mes pots précédents…