RGPD : un an après

Le règlement général sur la protection des données introduit un changement majeur de paradigme dans la protection des traitements de données personnelles, puisque l’on passe d’une logique administrative à une approche par le risque. Il ne s’agit plus simplement de déclarer un traitement pour qu’il soit conforme, il s’agit de procéder à une appréciation des risques que l’on fait encourir aux personnes dont les données sont traitées (et le RGPD ne dit pas comment la réaliser), de réduire les risques que l’on estime majeurs (et le RGPD ne dit pas lesquels) et d’effectuer une réévaluation périodique du dispositif (et, bien entendu, le RGPD ne dit pas comment). En d’autres termes, il s’agit d’une totale inversion de la charge de la preuve. Avec la réglementation précédente, une fois l’imprimé rempli, il appartenait à la Cnil de démontrer que le traitement était non conforme. Avec le RGPD, c’est l’inverse : il appartient au responsable de traitement (RT) de démontrer qu’il a suivi le règlement dans l’esprit sinon à la lettre et qu’il a, en toute bonne foi, pris les mesures nécessaires pour sécuriser le traitement.

L’entropie comme première approche

Tous les délégués à la protection des données (DPD, ou DPO selon le sigle anglais) ont abordé le RGPD peu ou prou de la même manière : par les fondamentaux. C’est ainsi que les consultants, les juristes et les DPO ont d’emblée évoqué les concepts de Privacy by Design, de registre des traitements (qui existait déjà du temps des correspondants Informatique et Libertés – les CIL), de l’appréciation des risques, du Privacy Impact Assessment, etc. Mettre en place ce genre de brique ne présente pas de difficulté particulière au sein d’un établissement de santé, qui a déjà vécu des démarches qualité depuis le début des années 2000, dans la mesure où le RGPD n’est rien de plus qu’une démarche par le risque, donc une démarche qualité.

Par exemple, la mise en place du vote électronique dans les établissements de santé, pour les prochaines élections professionnelles, rentre exactement dans cette démarche, et les DRH, pour ce que nous en savons, sont tout à fait sensibles à cette approche. Après tout, il faut bien sécuriser la distribution des identifiants sur la plateforme de vote (qui est quasi systématiquement externalisée en mode SaaS), il faut bien prévoir des systèmes de recouvrement des mots de passe, il faut bien sécuriser la phase de dépouillement. Chacun comprendra aisément que les contre-mesures aux risques identifiés ont leurs limites et que la MOA, à un moment donné, doit bien sortir de la phase d’appréciation des risques en acceptant les risques résiduels, car le RGPD ne parle jamais de risque zéro. Il arrive que le DPO doive « manger son chapeau », mais à cela rien d’anormal : le RGPD stipule qu’il n’a qu’un rôle de conseil et d’alerte, et la MOA reste propriétaire de ses risques, pour le RGPD comme pour le reste.

Il y a certes la question de l’antériorité : quid des traitements déjà en place, dont une bonne partie est sensible et nécessiterait dans l’idéal de passer à la moulinette du PIA ? En toute rigueur, les traitements déjà conformes n’ont pas à être révisés sauf modification substantielle, mais c’est sans doute un point de débat et, en tout état de cause, une revue réduit considérablement le risque de contentieux, d’autant que la Cnil la recommande vivement. Selon nos estimations, un établissement de soins de grande taille aligne environ 35 traitements (qui couvrent donc tous les processus), dont à peine la moitié peut être estampillée « sensible ». Paris ne s’étant pas fait en un jour, il est fortement conseillé de démarrer par les plus sensibles de la liste, à savoir le DPI (volet administratif et médical), la médecine du travail, la gestion des fiches d’événements indésirables, l’Active Directory et les RH.

La question se complique dès lors que l’on aborde l’épineux sujet des relations contractuelles entre le responsable de traitement (RT) et le fournisseur (titulaire du marché, mais sous-traitant – ST – au sens du RGPD). Là encore, il y a l’antériorité, et le futur. Pour ce qui concerne l’antériorité, les juristes stipulent que l’ensemble des contrats existants est à revoir et doit faire l’objet d’avenants précisant la répartition des rôles entre le RT et le ST sur les traitements mis en œuvre. Dans un CHU, c’est tout bonnement impossible : des milliers de marchés sont en cours, et une telle charge de travail ne peut pas être assumée. Il va donc falloir faire des choix, évidemment dictés par les risques associés aux traitements les plus sensibles et aux fournisseurs en position de ST sur ces traitements.

Au premier stade, le DPO lutte contre l’entropie – le désordre – qui constituait un état de fait à l’arrivée du RGPD, puisque les dispositions qu’il contient n’avaient jamais été prises en compte. Le DPO évolue en réalité sur un puzzle dont il doit progressivement agencer les pièces, mais dans un environnement où les bords du puzzle bougent constamment, puisque de nouveaux traitements, de nouveaux marchés, apparaissent sans cesse. Le principal défi consiste à capter la mise en place de ces traitements.

Capter les traitements

Rapidement, le DPO comprend que la mise en conformité n’est ni sa seule tâche ni la plus compliquée : être en amont de tout nouveau traitement, donc en avoir connaissance, devient son enjeu principal. Penser que tout traitement nécessite un logiciel, tout logiciel une acquisition qui passe par la DSI, et donc que la seule source des traitements dans un établissement est la DSI est erroné. Tous les logiciels ne sont pas forcément achetés par la DSI, tous les logiciels ne sont d’ailleurs pas forcément achetés (il existe de nombreux cas de prêt de logiciels ou de matériels qui ne passent par aucun circuit d’achat formalisé) et tout traitement n’a pas forcément pour origine une acquisition de logiciel.

C’est ainsi que l’on trouve des traitements issus de l’acquisition de matériels biomédicaux (qui ne passent généralement pas par la DSI), issus de requêtes sur des bases de données nominatives (entrepôt de données RH ou médicales par exemple), issus de l’acquisition de prestations diverses (assurance en responsabilité civile pour les accidents médicaux, vote électronique, commande de matelas thérapeutiques par le biais d’un portail Web, etc.), issus de projets de recherches cliniques ne relevant pas des MR(1) de la Cnil, issus de prêts de matériel, par exemple en génétique, etc.

L’enjeu du DPO consiste à se positionner le plus possible en amont de ces traitements pour en capter l’existence. Si la DSI est le premier interlocuteur du DPO au sein de l’établissement, la direction générale (qui voit passer tous les projets) et la direction des achats (qui voit passer tous les marchés) sont sans aucun doute les suivants, sans parler bien entendu des équipes biomédicales, des services techniques, des équipes de sécurité – bref de toute l’ingénierie –, de la DRH, des équipes gérant les entrepôts de Big Data des données de santé, etc. Une intervention, renouvelée a minima tous les ans, dans les staffs de ces équipes fait partie des actions incontournables du DPO.

Le DPO quitte forcément la casquette de pilote d’un processus administratif bordé, pour porter celle d’un accompagnant, d’un facilitateur, d’un pédagogue. Le DPO est en mode soft power : convaincre plutôt que contraindre, faire adhérer plutôt qu’être intrusif. La question n’est pas que le DPO ne doive pas être partie prenante dans un traitement, la question est que le job est plus facile pour lui s’il ne l’est pas : le DPO doit mettre en place des processus en mode roue de Deming, et veiller à ce que ces roues tournent. Pas vite, mais en permanence.

À ce stade avancé, le second enjeu du DPO est de rassurer. L’expérience montre que les experts techniques (à entendre au sens large du terme, c’est-à-dire aussi bien les informaticiens que les acheteurs ou les juristes) peinent à envisager une obligation réglementaire autrement que « tout, tout de suite » au lieu de l’aborder sous l’angle de Deming en mode PDCA (2). Le DPO doit faire preuve de pédagogie et amener ces équipes à aborder le RGPD – qui est un monstre de charge de travail – sous l’angle de Pareto : on va s’attaquer aux 20 % les plus sensibles et compliqués en laissant les 80 % restants en stand-by, puis, quand on aura terminé, on va prendre les 20 % des 80 % restants, etc. Le DPO est-il d’ailleurs autre chose qu’un qualiticien ?

La question des indicateurs à mettre en place est du reste alors posée. Au premier stade de maturité RGPD, il est tentant de compter les traitements conformes – c’est la vision statique des indicateurs. Au second stade de maturité, il faut surtout compter les roues qui tournent en plus – c’est la vision dynamique. Le DPO travaille sur le terrain de la gouvernance plutôt que sur celui de la technique. Et cette approche est majeure dès lors que l’on passe à l’échelon GHT.

L’échelon GHT

À l’échelon GHT surgissent deux difficultés supplémentaires : la taille, et la taille. La taille parce qu’aucun DPO ne peut mener dans un GHT, parfois 50 % plus large que son établissement d’origine, la même démarche : trop gros, trop éclaté, typologies d’activités trop diverses. Et la taille, une seconde fois, car si la démarche relative aux processus métiers au sein du GHT n’est pas engagée (marche vers une DSI unique, travaux RH communs, processus achat unifié, etc.), le DPO de l’établissement support va s’épuiser en pure perte.

La factorisation souhaitable du socle documentaire est indispensable : inutile de demander à chaque DPO ou relais DPO des établissements périphériques de réinventer la roue, inutile que chacun refasse le PIA de son AD ou des traitements RH, autant factoriser à l’échelle de l’établissement support. Le DPO « central » aura d’ailleurs assez à faire avec la résolution de questions pas si simples, telles que le partage des données RH (qui est le RT ? quelle est la légitimité du traitement ?) ou la convergence du DPI (quelle politique d’habilitation ?), la responsabilité du DPO de l’établissement support en cas d’incident dans un établissement périphérique (les textes ne sont pas clairs) ou encore la réponse aux sollicitations des équipes de direction de l’ensemble du GHT sur l’implication des décideurs dans le RGPD. À ce sujet, le choix des relais DPO sur le terrain est une question cruciale, l’expérience montrant que les qualiticiens sont de bien meilleurs candidats que les informaticiens.

RSSI et DPO, RSSI ou DPO ?

Les travaux sur des projets tels le vote électronique, la mise en conformité du DPI et autres font apparaître une réalité étonnante : alors que le RGPD insiste bien sur le fait que les risques à évaluer sont ceux que l’on fait encourir aux personnes dont on traite les données, votre serviteur n’a pas un seul exemple, à l’heure de rédaction du présent article, d’un risque pour les personnes qui ne soit pas en même temps un risque pour l’établissement : après tout, si risque pour les personnes il y a, par ricochet, a minima un risque juridique existe pour l’établissement ! La question de savoir si le DPO et le RSSI doivent être des personnes différentes n’est donc ni vraie ni fausse, elle est tout simplement hors de propos : le risque IT se confond avec le risque IL (Information Legacy), et il y a fort à parier que RSSI et DPO rejoindront dans les prochaines années une équipe « Conformité ». D’autant que le levier réglementaire du RGPD offre au RSSI des opportunités uniques de faire avancer la SSI, situation paradoxale a priori, mais dans les faits totalement partagée. Quand on tombe sur un consultant qui commence sa démarche par la question du recouvrement DPO/RSSI, c’est qu’il a clairement trois trains de retard en termes de maturité dans ce domaine : le DPO doit travailler conjointement avec le RSSI. Et que la même personne occupe ces deux fonctions ne gâte rien.

Conclusion

Si l’échelle Cobit (six niveaux, de 0 à 5) est faite pour mesurer la capacité de l’IT à s’aligner sur la stratégie de l’établissement, elle n’est pas adaptée à la mesure de la maturité du processus RGPD. Approche administrative, approche risque ou approche processus PDCA, c’est peut-être la bonne échelle, sur trois niveaux. Avec les GHT, toute démarche qui n’est pas au niveau 3 ne pourra pas attaquer l’ensemble des établissements du groupement. Et, a contrario, tout GHT qui n’a pas engagé une refonte des processus métiers transversaux ne peut prétendre à une démarche RGPD de niveau 3. Le RGPD arrive en pleine mise en œuvre des GHT : opportunité ou contrainte ? Opportunité sans aucun doute.

Enfin, le RGPD est un galop d’essai (au sens où ce n’est pas le dernier) : attention à la directive NIS… Des factorisations de socle documentaire, d’audit interne, d’équipe de mise en œuvre vont rapidement devenir obligatoires sous peine d’épuiser la technostructure de l’établissement.

Rendez-vous les 2, 3 et 4 avril 2019 au Mans, pour 20 conférences préparées pour l’événement : S’inscrire au Congrès 2019 : https://www.apssis.com/le-congres-2019/inscriptions.html

[1]   Méthodologies de référence appliquées à la recherche clinique.

[2]   Plan, Do, Check, Act, ou l’amélioration continue symbolisée par la roue de Deming.

*Responsable Sécurité des systèmes d’information et DPO du CHU de Nantes et du GHT44, Cédric Cartau est chargé de cours à l’EHESP et à l’ESIEA. Il collabore régulièrement à la revue DSIH et a publié différents ouvrages, notamment la seconde édition de La Sécurité du système d’information des établissements de santé (Presses de l’EHESP, 2018). 

En savoir plus sur la formation Certified Data Protection Officer ici