LES ÉCHANGES DE DONNÉES À CARACTÈRE PERSONNEL ENTRE LES ADMINISTRATIONS
Propos introductif
Les échanges de données entre administrations doivent être replacés dans leur contexte. En effet, en raison du développement technologique et numérique, les administrations, dont le SPF Finances, ont dû adapter leurs méthodes de fonctionnement et de travail afin de traiter de manière efficace les éléments d’informations dans le cadre de leurs missions. A cet effet, la méthode de fonctionnement des administrations a progressivement changé de cap, allant d’un fonctionnement cloisonné de chaque administration vers une méthode de collecte unique. Cette ouverture progressive entre administrations poursuit deux objectifs. D’une part, simplifier la tâche de l’administration qui n’a plus besoin de traiter et collecter individuellement les données à caractère personnel et, d’autre part, simplifier la tâche du citoyen qui ne communique ses données qu’une seule fois. A cet effet, le législateur belge avait déjà adopté en 2012 la mise en œuvre d’un «intégrateur de services» qui sert de point de transit et de point de contact au niveau des sources authentiques de données.
Les échanges de données à caractère personnel entre administrations consistent en des échanges de données opérés sur base d’une collaboration entre les différentes administrations de l’Etat belge. En pratique, un transfert de données relatives aux revenus pourrait avoir lieu entre le SPF Sécurité Sociale et le SPF Finances, ce dernier voulant connaître la situation familiale d’un contribuable, par exemple. Cette matière a également fait l’objet de certains aménagements suite à l’adoption du RGPD.
La situation avant le RGPD
L’autorisation préalable des Comités sectoriels :Avant l’entrée en vigueur du RGPD en date du 25 mai 2018, les échanges internes de données à caractère personnel entre autorités publiques était balisé par la mise en place de comités sectoriels auxquels il fallait demander une autorisation. Ces comités sectoriels faisaient partie de l’organisation interne de l’ancienne CPVP (Commission pour la Protection de la Vie Privée). Concrètement, les différentes administrations étaient les gardiennes de ce que l’on dénomme «des sources authentiques de données». Ces sources authentiques de données consistent en des bases de données dont les administrations sont les responsables en termes de vérification d’exactitude, de mise à jour et de sécurité.
Lorsqu’une entité devait consulter une de ces bases de données, elle devait demander une autorisation au Comité sectoriel compétent. A cet effet et conformément à l’ancien article 36bis de la loi « Vie privée », le Comité sectoriel compétent pour le SPF Finances était le Comité sectoriel Autorité Fédérale. Celui-ci disposait de la compétence d’autorisation relative à l’accès aux sources authentiques de données détenues par un Service Public Fédéral ou un organisme public doté de la personnalité juridique dépendant de l’autorité fédérale. Ce Comité Sectoriel était donc compétent pour les autorisations d’accès aux données contenues dans les sources authentiques gérées par le SPF Finances. Le Comité Sectoriel pour l’Autorité Fédérale disposait donc d’un certain pouvoir, dans la mesure où il pouvait refuser l’accès aux données à caractère personnel contenues dans les bases de données du SPF Finances.
Les motifs de suppression des Comités sectoriels :Etant donné l’étendue des pouvoirs des comités sectoriels, il fallait instituer un contrôle des différentes décisions ce qui ne semble pas forcément avoir été le cas. En effet, le système mis en place par le législateur avant le RGPD paraissait déjà critiquable au niveau de l’indépendance, de l’impartialité, et de l’absence de voies de recours contre les décisions des comités sectoriels.
Le législateur avait mis en exergue trois motifs qui justifiaient, selon lui, la suppression des comités sectoriels.
Dans un premier temps, le législateur estimait que le cadre légal dans lequel opéraient les Comités Sectoriels était imprécis voire lacunaire, en ce sens qu’ils n’avaient pas une compétence bien délimitée et demeurait silencieux pour ce qui est des procédures pour lui soumettre des autorisations.
Les problèmes liés à la suppression des Comités sectoriels
Initialement, le législateur n’avait pas prévu de contrôle remplaçant celui opéré par les Comités sectoriels. Par conséquent, les échanges de données prévus par les protocoles sont potentiellement en proie à des dangers.
Un des problèmes pointés par la doctrine est le fait que la loi ne prévoyait pas des exigences de mentions dans les protocoles. Ceci induit que les administrations étaient libres d’entériner le contenu qu’elles veulent dans les protocoles. A cet effet, le Conseil d’Etat n’a pas manqué de faire remarquer qu’utiliser le verbe « pouvoir » dans la loi renvoie à une appréciation libre de la part des autorités publiques, ce qui entraînerait une insécurité juridique et une entrave au principe constitutionnel de légalité. Les exigences de loyauté et transparence prévues dans le RGPD prohibent le caractère opaque des traitements de données dans le cadre de transferts de données entre organismes publics. Ce principe a notamment été illustré dans l’arrêt Smaranda Bara de la CJUE.
En vue de répondre à l’absence de contrôle reprochée à l’ancien système, l’article 35/1 § 2 de la loi du 15 août 2012 relative à la création et à l’organisation d’un intégrateur de services fédéral prévoit désormais la possibilité d’un contrôle par l’Autorité de protection des données sur les délibérations émises par le Comité de sécurité de l’information .
Le Comité de Sécurité de l’information et les protocoles
Concernant spécifiquement la mise en place du Comité de sécurité de l’information, on peut s’apercevoir que le législateur a opéré un rétropédalage. A cet effet, le Conseil d’Etat avait déjà dénoncé cette incohérence dans son avis du 26 avril 2018. En effet, le RGPD a consacré le principe d’accountability, qui a pour but de responsabiliser les responsables de traitement. C’est dans cet ordre d’idées que le législateur belge a mis fin au système des formalités préalables aux traitements de données, en abrogeant les mécanismes d’autorisation des Comités sectoriels. Cependant, lorsqu’on analyse la loi du 5 septembre 2018, le législateur semble être revenu en arrière, dans la mesure où il a fait « renaître » les Comités sectoriels pour la sécurité sociale, ainsi que celui pour l’autorité fédérale, compétent pour le SPF Finances. Le législateur a fait renaître ces comités par le biais des chambres compétentes du Comité de Sécurité pour l’information. Ainsi, soumettre à un examen de légalité préalable une communication de données à caractère personnel à la chambre de l’autorité fédérale du CSI contreviendrait d’une part, au principe d’accountability consacré par le RGPD et d’autre part, au système des protocoles d’échanges prévus par la LTD.
La notion de datawarehouse
Définition
Dans son sens commun, un datawarehouse renvoie à l’expression française d’« entrepôt de données ». La notion est définie à l’article 5 §1er 1° de la loi du 3 août 2012.
En termes techniques. Un datawarehouse « est une plateforme utilisée pour collecter et analyser des données en provenance de multiples sources hétérogènes ». En d’autres termes, un datawarehouse consiste donc en une masse de données sur lesquelles on peut procéder à des analyses. Le datawarehouse du SPF Finances n’est pas le seul à être mis en place au sein des administrations belges. En effet, l’ONSS au sein du SPF Sécurité Sociale dispose d’un outil similaire que l’on appelle OASIS. Le datawarehouse OASIS, outil très efficace contre la fraude sociale, fait néanmoins l’objet de critiques quant à sa compatibilité avec plusieurs droits fondamentaux, notamment le droit à la vie privée et le droit à la transparence de l’administration.
La controverse autour du datawarehouse
Concernant la création d’un datawarehouse au sein du SPF Finances, une critique avait déjà été mise en 2014 concernant la mise en place d’un datawarehouse. En effet, la loi manquait déjà de précisions quant à la provenance des données des contribuables et à la possibilité pour les contribuables de corriger les données se trouvant sur ce datawarehouse.
En 2018 également, lors de la mise en œuvre des principes du RGPD, la section Législation du Conseil d’Etat s’était montrée critique vis-à-vis de cette masse systémique de données. En effet, la section Législation estime qu’il appartient au législateur de fixer avec précision les catégories de données mises à disposition du SPF Finances au sein de ce datawarehouse ainsi que les finalités pour lesquelles les données pourraient être traitées.
En outre, il appartient également au législateur de prévoir avec précision les modalités de collecte et « les éléments permettant de vérifier la pertinence et la nécessité de l’intégration de ces données à caractère personnel, ainsi que la durée de conservation de celles-ci, le responsable du traitement, les personnes autorisées à consulter la base de données et les conditions de réutilisations de données traitées. On ignore également si la réutilisation de données qui est ainsi envisagée sera faite à des fins distinctes de celles pour lesquelles elles ont été collectées ». A en croire l’avis de la section législation du Conseil d’Etat, la situation ne semble pas avoir changé depuis l’adoption de la loi du 3 août 2012 puisque des critiques demeurent autour des règles qui encadrent le fonctionnement du datawarehouse et les traitements de données à caractère personnel qui y sont opérés.
Le data Matching, le datamining et le profilage
Le data Matching, en français « couplage de données » consiste à regrouper des données figurant sur un datawarehouse et à les comparer entre elles. La notion est définie à l’article 5 §1er 3° de la loi du 3 août 2012 comme « la comparaison entre plusieurs sets de données rassemblées ». Le datamining, en français « extraction de données », consiste en ’opération postérieure, à savoir l’opération sur base de laquelle on va appliquer des algorithmes qui vont permettre de faire ressortir des données nouvelles. Le datamining est défini à l’article 5 §1er 4° de la loi du 3 août 2012 comme «la recherche de manière avancée d’informations dans de gros fichiers de données ». C’est grâce à ce processus qu’il est possible d’effectuer des activités de profilage. Le profilage consiste à prendre une décision sur base d’un traitement automatisé de données. A cet égard, l’article 5 §1er al 1er de la loi du 3 août 2012 renvoie simplement à la définition contenue à l’article 4.4 du RGPD. Afin d’illustrer notre propos, E. DEGRAVE propose cet exemple théorique : « En guise d’exemple simple, prenons le cas de John, dont les données fiscales montrent qu’il gagne 2.000 EUR par mois. Or, ses données à la DIV montrent qu’il détient 7 Ferrari neuves. Le Registre national indique qu’il est propriétaire de deux châteaux. Les algorithmes «anti-fraude» vont cibler John. Il sera rattaché à la catégorie des présumés fraudeurs fiscaux et sociaux et un contrôle fiscal et/ou social sera encouragé. » .
|
Table des matières
I. INTRODUCTION
II. PARTIE 1 : LA PROTECTION DES DONNEES A CARACTERE PERSONNEL EN BELGIQUE : PRESENTATION SOMMAIRE
1) PROPOS INTRODUCTIFS
2) LE RGPD
a. Les motifs liés à l’adoption du RGPD et ses objectifs
b. La structure du RGPD
c. Critique du RGPD
d. Cadre législatif belge
III. PARTIE 2. LES ECHANGES DE DONNEES A CARACTERE PERSONNEL ENTRE LES ADMINISTRATIONS
1) PROPOS INTRODUCTIF
2) LA SITUATION AVANT LE RGPD
a. L’autorisation préalable des Comités sectoriels
b. Les motifs de suppression des Comités sectoriels
3) L’IMPACT DU RGPD SUR LES ECHANGES DE DONNEES : LE SYSTEME DES PROTOCOLES
a. Les problèmes liés à la suppression des Comités sectoriels
b. Le rôle du DPO et le contrôle interne du protocole
c. Le Service Privacy et Security
d. Le Comité de Sécurité de l’information et les protocoles
e. Les problèmes liés aux sanctions
f. Les autres mesures techniques et organisationnelles du SPF Finances..
i. L’IAM (Identification Access Management)
ii. Le PIA (Privacy impact assessment)
g. Brève conclusion
IV. PARTIE 3: LES NOTIONS DE DATAWAREHOUSE, DATAMINING, DATAMATCHING ET PROFILAGE
1) LA NOTION DE DATAWAREHOUSE
a. Définition
b. La controverse autour du datawarehouse
2) LE DATAMATCHING, LE DATAMINING ET LE PROFILAGE
V. CONCLUSION
Télécharger le rapport complet