Protection des données personnelles et recommandations dans l’OPAC




Une fonction vraiment intéressante dont j’ai déjà
beaucoup parlé est celle qui permet d’afficher à l’OPAC : "les lecteurs ayant emprunté ce livre ont aussi emprunté" elle repose sur le bouche-à-oreille, version numérique! (j’adore l’image ci dessus, même si elle fait plus téléphone-arabe que bouche-à-oreille, mais bon…)

J’avais écrit il y a presque deux ans un billet qui faisait (du moins le croyais-je alors) un sort à l’objection spontanée (et légitime) suivante : "mais si on recommande c’est qu’on réccupère l’historique des prêt et ça c’est des données personelles et la CNIL l’interdit!"

En fait la CNIL ne l’interdit pas puisque dans l’article 2 de la NORME SIMPLIFIEE, DELIBERATION N° 99-27 du 22 avril 1999:

Les traitements doivent avoir pour seules fonctions :
– de fournir des informations individuelles pour la gestion financière des prêts et la récupération des ouvrages ou supports prêtés ;
– d’éditer des états statistiques dépersonnalisés pour les besoins de gestion et d’amélioration des services rendus (nature des ouvrages les plus souvent consultés, nom des oeuvres et des auteurs ou références des documents d’archives, etc.)

On aura compris que ces données peuvent être conservées si elles sont anonymes. Soit. Or, Paul Poulain, consultant indépendant en logiciels libres et responsable de Koha, m’a montré dans un échange de mails que les choses ne sont pas si simples: (merci à lui 🙂

En effet, l’article 4 du même texte indique (j’aurai dû mieux lire le texte il y a 2 ans!) :

Les informations relatives à l’identité des emprunteurs sont conservées tant qu’ils continuent à participer au service de prêts. La radiation peut être demandée par l’emprunteur lui-même.
Lorsque celle-ci n’est pas demandée par l’emprunteur, elle doit intervenir d’office et dans tous les cas à l’issue d’un délai d’un an à compter de la date de fin de prêt précédent.
Les informations concernant chaque prêt sont conservées jusqu’à la fin du quatrième mois suivant la restitution de l’objet du prêt. Au-delà de ce délai, les informations sur support magnétique sont détruites ; elles ne peuvent être conservées sur support papier que pour les besoins et la durée d’un contentieux éventuel.

On passera sur le "support magnétique" remplacé par le numérique, tant il est vrai que ce type d’usage était hors de propos en 1999 à l’heure de la rédaction de cette norme…En revanche la CNIL a bel et bien bien prévu dès 1999 une limite de conservation des données de prêts : 4 mois!

L’inconvénient principal est que les algorithmes qui permettent les recommandations sont d’autant plus efficaces que les données qu’ils gèrent sont importantes. Autrement dit, plus on conserve des données longtemps et/ou plus on traite une base de données importante, plus les recommandations ont des chances d’être pertinentes.

A l’heure où les prestataires affutent leurs armes 2.0 pour nous vendre des logiciels et des OPAC, il est largement temps d’être au clair sur ces questions, d’autant que les enjeux politiques sont essentiels en termes de protection de la vie privée

Cela semble imposer deux solutions.

On demande l’assentiment de chaque lecteur, à l’occasion de l’inscription ou du renouvellement d’inscription afin de conserver les données plus longtemps. C’est ce que propose Paul Poulain :

En ce qui me concerne, je pense que la seule manière de faire (et qu’on va essayer d’implémenter dans Koha), c’est de permettre aux lecteur, à l’OPAC, d’explicitement demander que l’on conserve ses données. Avec une option pour effacer immédiatement tous les emprunts. Choix inaccessible aux bibliothécaires, ce sont des données privées.

Inconvénient : le système est lourd et il n’est pas sûr que beaucoup de lecteurs optent pour que leurs données soient conservées….(posez vous la question : vous accepteriez en tant qu’usager?)

Une autre solution (non exclusive de la première) pourrait être de travailler sur ces données pendant 4 mois. Mais alors :
à partir de quel volume de données les recommandations peuvent-elles être suffisamment pertinentes ?

Réponse de Paul Poulain (attention c’est un peu technique):

Voilà une excellente question. A mon avis, c’est une question de support : pour les "blockbuster", 4 mois sont tout à fait suffisants. Mais justement, tout le monde connait les blockbusters !

L’intérêt est pour la longue traine. En fait, on pourrait aboutir à quelque chose si l’on part de l’hypothèse suivante : l’intérêt est concentré dans le temps

Exemple : "je m’intéresse à la culture des tomates en milieu méditerranéen". Sur 3 mois je vais prendre un max de documents sur le sujet. Le système peut alors enregistrer que, "quelqu’un" a emprunté A et B "en même temps". Information qui peut être totalement anonyme.On stocke les "doublons". J’emprunte par exemple : (A) "tomates mode d’emploi", (B) "tout réussir dans son jardin" et (C) "Harry potter et l’ordre du phenix" (qui n’a rien à voir, nous sommes d’accord 😉 )

On stocke : AB = 1, AC=1, BC=1. Si d’autres, sur le même délai de 4 mois empruntent AB, nous faisons AB=2, AB=3 … Ainsi, AB a un gros indice, AC restera surement un faible indice. Et nous pourrions, sans limite de temps afficher "tomates mode d’emploi" => "tout réussir dans son jardin".

La seule limite à l’algorithme, c’est qu’il ne marche que si on s’intéresse à un sujet fortement pendant un laps de temps "court". Parce que si j’emprunte A en janvier et B en septembre, "AB" ne sera pas du tout mis à jour (puisqu’on n’a jamais l’info A/B en même temps dans la base)

On aura compris que le système n’a des chances de fonctionner de manière satisfaisante qu’avec des tailles critiques de catalogues importantes…la question est alors : Quelle taille? Il est important  à cet égard de ne pas construire des cahiers des charges exigeant ces fonctions pour de trop petites structures. Paul Poulain on compte sur vous pour nous tenir au courant hein! 🙂

Encore une fois je suis sûr que c’est le logiciel libre en bibliothèque qui va être le premier à innover sur ces fonctionnalités. Il y a des chances que ça se passe au SAN Ouest Provence qui vient d’installer Koha dans son réseau de 6 bibliothèques. Qui plus est parce que ce SAN salarie 3 développeurs dont le travail, en plus de bénéficier aux usagers, bénéficiera à tous les utilisateurs des futures versions de Koha ! (merci les contribuables du sud de la France!)

Quitter la version mobile