RGPD, poids des responsabilités

[michael.]

Bonjour,

Je suis du (très) mauvais côté de la barrière, c'est-à-dire :

• éditeur de logiciel,
• à mon compte (je n'ai pas de juriste pour m'aider),
• travaillant pour un institutionnel,
• sur un logiciel qui traite de données sensibles.

Et pas du côté de ceux à qui cette loi profite financièrement, c'est à dire principalement : juristes, cyber-experts et ransom-hackers...

Je suis du côté de ceux qui en payent le coût car je dois mettre en conformité un site web. Je dois payer au prix fort cela car cela n'était pas prévu dans mon contrat initial. Je dois intégrer des dizaines de fonctionnalités à un site et des jours supplémentaires de développement mais surtout cela crée une véritable inquiétude psychologique.

Si les principes directeurs et philosophiques du RGPD sont louables, la façon dont celui-ci s'est matérialisé, me parait extrêmement sujette à interprétation et me met hors de moi en termes d'exigences et de demandes. Imaginez vous avez une bijouterie, vous vous faites voler, celui qui est responsable aujourd'hui c'est le bijoutier car il aura mal sécurisé son magasin. Je pense que nous avons trouvé en Europe "l'usine à gaz" pour définitivement tuer l'innovation et le développement logiciel.

Je ferme la parenthèse, ce qui me "terrorise" en particulier c'est l'ineptie de devoir faire la preuve que l'on peut "prévenir toute violation de données". Ce mot "toute" ? Quelqu'un a t-il réfléchi à cela ?

Il y a des millions de lignes de codes dans un système d'exploitation. La somme des logiciels utilisés pour pouvoir mettre à disposition ne serait-ce qu'un site web est terriblement importante. Il n'y a pas un individu sur Terre capable de "tout" maîtriser et de tout savoir. Et pourtant je suis dans l'informatique depuis près de 40 ans. Les failles en générales sont découvertes de manière inattendue, parfois elles restent dormantes des années avant qu'elles soient relevées. Quel est l'âne qui a écrit qu'il fallait "prévenir toute violation de données" ? Quelqu'un qui visiblement ne connait pas le logiciel, ou alors un élitiste de la cyber-sécurité. Mais là aussi, c'est se leurrer que de croire une sécurité inviolable.

Je ne développerai pas plus, car devoir demander à l’éditeur de logiciel ou au développeur de devoir faire la preuve que l'ensemble des briques technologiques qu'il met en œuvre sont "infaillibles" me semble aussi absurde que dire que 1+1=3.
Face à ce constat "impossible", en termes de logiciels à vocation "sociétale", cela ne laisse à mon sens de la place qu'au gros éditeurs qui ont les moyens de se rapprocher de cette protection "idéale" et qui sinon peuvent financer des avocats pour se couvrir du risque.

Enfin ma question: il y a dans ce contexte compliqué une information qui me manque, qui rend à mon sens les choses encore plus anxiogènes : je développe un logiciel dans le cadre d'un contrat. Dans un an mon contrat est clos. Combien de temps vais-je rester responsable des failles ou des problèmes de protection s'il y en a après que je sois parti qui soient découvertes ? Jusqu'à quand s'étend ma responsabilité en tant que développeur logiciel ?

 

[emualliug]

Le règlement européen n'emploie pas l'expression « prévenir toute violation de données ».

Et en fait, si on en revient au texte, l'exigence est beaucoup plus raisonnable (article 32, sécurité du traitement) :

Compte tenu de l'état des connaissances, des coûts de mise en œuvre et de la nature, de la portée, du contexte et des finalités du traitement ainsi que des risques, dont le degré de probabilité et de gravité varie, pour les droits et libertés des personnes physiques, le responsable du traitement et le sous-traitant mettent en œuvre les mesures techniques et organisationnelles appropriées afin de garantir un niveau de sécurité adapté au risque.

Le RGPD a été édicté en 2016, il est applicable depuis 2018 (deux ans pour anticiper tout de même), une bonne partie des obligations préexistaient (notamment en France avec la loi de 1978). Si tu es un professionnel de l'informatique, tu dois être au courant de la réglementation des activités. C'est comme exiger d'un fabricant de produit agro-alimentaires qu'il soit au fait des règlements d'hygiène.

Sur la durée de la responsabilité, difficile de répondre. À mon sens, pour un contrat sans suivi ni maintenance, tu ne peux être tenu que des failles et bonnes pratiques connues à l'époque de la livraison. Si demain une nouvelle faille est découverte dans Jquery, on va pas te reprocher d'avoir inclus la version antérieure où la faille existe, le correctif n'existant pas au moment de la livraison. Par contre, une page de ton appli est sensible à de l'injection SQL parce que les inputs ne sont pas correctement traités, ça devrait être pour ta pomme, même si la faille n'est exploitée que dans plusieurs années.

 

[michael.]

Merci pour ce retour.

Pour rebondir, c'est bien la CNIL qui emploie cette terminologie :

Au titre de ce principe essentiel, ces organismes doivent mettre en place des mesures visant à :

• prévenir toute violation de données
• réagir de manière appropriée en cas de violation, c'est-à-dire mettre fin à la violation et minimiser ses effets.

Cependant, je pense qu'elle fait référence plutôt à l'article l'article 83 et qu'elle en a fait une réinterprétation "à sa sauce" :

Afin de garantir la sécurité et de prévenir tout traitement effectué en violation du présent règlement, il importe que le responsable du traitement ou le sous-traitant évalue les risques inhérents au traitement et mette en œuvre des mesures pour les atténuer, telles que le chiffrement.

Si c'est cela, c'est tout aussi flippant d'observer cette libre réinterprétation. Encore plus si c'est la CNIL qui doit juger que vous avez "bien" ou "mal" fait les choses.

Vous écrivez:

Sur la durée de la responsabilité, difficile de répondre. À mon sens [...]

Vous convenez qu'il n'y a pas de réponse claire à cette question dans les textes cités.

Que par conséquent cela est bien soumis à l'interprétation individuelle, personnelle et subjective de chacun. Et comment cela se passe pour un code dont le développement s'est étalé sur plusieurs années ? Ce sera jugé en fonction du moment ou des failles existaient pour chacun de ces morceaux de codes ? Ou alors, que je dois en permanence scruter le code que j'ai développé il y a plusieurs mois, voire même le code qui tourne dans chacun des modules du serveur parce que finalement j'ai continué à développer autre chose sur ce même serveur ? C'est dément, car la somme de code à actualiser et vérifier augmente au fur et à mesure.

Et si demain un autre développeur reprend le développement de ce logiciel et modifie le code, qu'elle sera ma responsabilité vis-à-vis de cela ? Si c'est l'interaction entre son code et mon code qui produit la faille ? Ou si la faille vient d'un module logiciel que j'ai utilisé ?

"L'injection SQL" un grand classique, exemple "facile".
Mais connaissez-vous l'ensemble des failles technologiques existantes sur l'ensemble des logiciels d'un serveur web ? Moi non.
Je m'intéresse aux aspects essentiels de la sécurité, mais ce n'est pas ma profession je suis un développeur et je ne peux pratiquement pas suivre quotidiennement la presse geek des spécialistes de la cybersécurité. Ou alors je change de métier. J'ai honnêtement l'impression que ceux qui ont écrit ces articles de lois étaient ni des éditeurs de logiciels ni des développeurs.

 

[michael.]

La possible réponse à "Jusqu'à quand s'étend ma responsabilité en tant que développeur logiciel ?"
qui serait "je suis responsable à vie du code et de ses failles" me parait tout bonnement incroyable. Ben je me suis fait arnaquer sur une série de Renault dont le moteur était défaillant mais non remboursé car c'est arrivé après 150 000 kms. J'ai perdu. Le constructeur a fait sa loi tout seul. Courte responsabilité pour un machin qui peut vous tuer. Il décide aussi de ses propres durées de garantie. Pas à vie. J'en connais pas beaucoup d'ailleurs.

Cela me donne parfois le sentiment que ce n'est plus celui qui doit s'occuper de protéger les données qui est soutenu par le RGPD, mais c'est le voleur qui va en profiter pour trouver des failles et des moyens de rentrer : il va s'en frotter les mains, car le RGPD est devenu une excellente source de chantage !

Par exemple : https://info.haas-avocats.com/droit-digital/cybercriminalité-le-ransomhack-nouvelle-forme-dattaque-cybercriminelle

Et il aura plusieurs années devant lui pour le faire, puisqu'une fois que le développeur sera parti vaquer à d'autres tâches il pourra s'atteler à vérifier si l'une ou l'autre des milliers de "failles" potentiellement existante fonctionne.

J'observe aussi un problème dans ce type de raisonnement vis-à-vis des programmes d'Intelligence Artificielle. Il est impossible aujourd'hui de savoir "comment" le meilleur jeu de Go a battu l'homme (alpha go), il est le produit de millions de cycles d'évolution. Aujourd'hui l'homme essaye de décortiquer ces programmes pour essayer de savoir comment il joue tel qu'il l'a fait.Comment va t-il falloir raisonner face aux programmes évolutifs dont on ne peut prévoir précisément toutes les développements ? On arrête tout en Europe ?

Avec une vision pareille l'innovation va s'échapper à vitesse grand V outre atlantique. On a inventer le truc génial pour empêcher les GAFA de débarquer avec leurs outils d'IA, mais aussi de dresser un pare-feu à l'entrée de l'Europe qui doucement rentre en stase.

La force de l'IA en matière de traitement de données c'est sa capacité à extraire des patterns, à réaliser des liens à partir d'informations complexes, noyées dans la masse et pour ainsi dire d'informations "lambda".
Elle pourrait vous donner le nom de l'auteur même si celui-ci ne l'a écrit nulle part. Et inversement elle peut écrire comme certains auteurs.
Plus les IA ont accès à des masses importantes d'informations plus elles sont capables de recouper et de traduire des informations de plus en plus anecdotiques en données personnelles. Et en partant de n'importe quel type de donnée.

Sans aller jusque là, dès aujourd'hui il me serait possible de prendre de simple mots échangés sur ce forum de les recouper et de retrouver un auteur d'un post ou plusieurs posts.

Alors qu'un forum ne contient pas de données personnelles "explicite", un texte, une liste de mots est, en fait, par essence une information personnelle. Et il n'est pas nécessaire pour cela d'employer d'outils "avancés", juste de la vieille technologie et un peu de temps.

Encore donc une lecture subjective et très discutable (qui va le discuter, la CNIL ?) : un forum d'échange permet bien facilement d'accéder à des données personnelles.

Mais, demain cela changera, "ils" se rendront compte bientôt que "Oh! Miracle! Il est devenu très facile de retrouver quelqu'un à partir d'extraits de texte".
Tout va devenir une information personnelle. Ben là, on va peut-être commencer à voir le truc inique de la chose. Il faudra mettre un service de sécurité derrière le moindre petit site web. Il faudra tout mettre sous séquestre. Bravo, bravo.

Il faudra donc aussi mettre à jour l'usine à gaz RGPD.
Et encore plus d'argent pour les juristes et la cybersécurité. Yes.

Eh attention ! Je ne dis pas qu'il ne faut rien faire mais je pense sincèrement que le RGPD se trompe dans certaines de ses modalités depuis le début (d'autres sont tout à fait censées, ce n'est pas un point de vue holistique, je suis juste confronté à la "chose"). A mon sens, c'est avant tout une problématique de sourçage de l'information. Problématique qu'il faudrait prendre bien amont, au niveau des informations transférées sur les réseaux. Les enjeux majeur aujourd'hui sont (à mon sens) la lutte contre la désinformation, les discriminations, les attaques nominatives sous l'abri de pseudonymes.

Il faudrait mettre en place des mécanismes simples et universels d'authentification qui soient intégrés dans les couches basses d'échanges de nos réseaux et non pas au niveau applicatif. Les vrais enjeux de traçage et de sécurité sont là.

Enfin, je reviens aussi sur la terminologie du texte la CNIL qui décidément est à géométrie variable : "Prévenir tout traitement". L'absurdité du mot "tout" me rend pantois, mais le mot "prévenir" pose aussi un problème sémantique : il possède 3 sens principaux qui s'avèrent radicalement différent dans leur mise en œuvre (sachant que cela peut-être une combinaison de tout ou partie des trois) :

1. Anticiper : du domaine de l'amont afin d'éviter de faire face au problème,
2. Empêcher / éviter : trouver les solutions pour empêcher le problème de d'avoir des conséquences néfastes (avant ou pendant)
3. Alerter / faire savoir : du domaine de l'information transmise à autrui

Allez choisissez le(s) vôtre(s).

 

[emualliug]

'elle fait référence plutôt à l'article l'article 83

C'est pas vraiment un article ça, mais un "considérant", en gros un exposé de la motivation qui a conduit le parlement et le conseil à prendre les articles qui suivent. Ça peut éventuellement servir à interpréter les textes, mais ça n'a pas la même force qu'un article à proprement parler, d'où l'usage du conditionnel.

cette libre réinterprétation

La CNIL essayer de vulgariser le texte, de le rendre plus accessible. Forcément, c'est un peu simplifier au passage, oui, le but c'est bien d'éviter toute violation des données, au sens de "on va pas juste en empêcher certaines", mais si pour cela elle devait recopier le RGPD, autant renvoyer directement vers le document.

il n'y a pas de réponse claire à cette question dans les textes cités

Le RGPD c'est juste un texte au milieu d'un corpus juridique. Le responsable du traitement est responsable tant qu'il assure le traitement.

De ton côté tu es un éditeur de logiciel. Ce n'est pas toi qui choisit de traiter des données perso ni qu les manipule. À mon sens, le responsable du traitement, au sens du RGPD, ce n'est pas toi, c'est ton client. Après, suivant ton taf, tu peux avoir un statut de sous-traitant au sens du RGPD, et avoir une part de responsabilité.

Mais restons à l'hypothèse du "simple" éditeur de logiciel, c'est son client qui fixe les objectifs et contraintes en terme de RGPD. En tant que prestataire de service tu es tenu des obligations de tout prestataire. RGPD ou pas. Une faille dans le code avant ou après le RGPD, ça change rien, sinon que le client il va se faire taper plus fort sur les doigt et qu'il va te demander des comptes.

S'il fait bien son travail, quand que vous avez passé votre contrat, il a dû indiquer quelles attentes il avait de toi, prestataire, en matière de respect du RGPD.

cela est bien soumis à l'interprétation individuelle, personnelle et subjective de chacun

Pas vraiment. Il faut voir ce que dit le contrat, ce que dit la loi, ce qui a déjà été jugé. Bref, comme pour tout quoi.

"L'injection SQL" un grand classique, exemple "facile".
Mais connaissez-vous l'ensemble des failles technologiques existantes sur l'ensemble des logiciels d'un serveur web ? Moi non.

Exemple facile, certes, j'ai hésité avec le XSS. On trouve de la sensibilité à l'injection à des endroits ahurissants. Souvent par manque de rigueur, "la donnée ne peut être qu'un nombre, inutile de l'échapper dans la requête serveur" ou un projet qui évolue, un truc géré uniquement côté serveur initialement et puis finalement, on finit par ouvrir une "porte" niveau client.

Si on commençait seulement par éliminer toutes ces failles "bateau", ce serait déjà un gain énorme en terme de sécurité. Et je parle pas des mots de passe bidon, y compris sur des projets de haut niveau, et sur les fichiers sources .git laissés ouverts aux quatre vents.

Je m'intéresse aux aspects essentiels de la sécurité, mais ce n'est pas ma profession je suis un développeur et je ne peux pratiquement pas suivre quotidiennement la presse geek des spécialistes de la cybersécurité.

Tout dépend du niveau de sensibilité et donc de la sécurité requise. Si c'est un panier d'achat de livres de coloriages, je ne m'attends pas à grand chose d'autres que des pratiques élémentaires de sécurité.

Si c'est un site qui est destiné à recueillir des informations cruciales pour la sécurité de l'État, il va falloir faire mieux. Tout le monde n'est pas un expert en sécurité, et on n'a pas toujours besoin d'un niveau de sécurité expert. Mais si on a besoin un besoin impérieux de sécurité, et qu'on a pas la compétence, il faut faire comme tout le reste : externaliser.

 

[erwinol2]

Je dois payer au prix fort cela car cela n'était pas prévu dans mon contrat initial. Je dois intégrer des dizaines de fonctionnalités à un site et des jours supplémentaires de développement

Je ne suis pas sûr de comprendre. Si ce n'est pas prévu dans ton contrat, c'est donc hors-scope. Si le client désire une mise en conformité, ça passe par un nouveau devis.

Ou ai-je loupé quelque chose ?