Rapport explicatif

qu’elles contiennent avec une précision de 99,98 % à l’aide de quasi-identifiants (nom, prénom et date de naissance des personnes enregistrées). Si un identificateur de personne univoque tel que le NAVS est utilisé en plus, il n’en résulte pas, du point de vue du hacker, un gain de précision significatif. Au regard de la protection des données, l’utilisation systématique du NAVS par les autorités ne modifierait donc pas la situation de façon déterminante. L’expert expose en outre divers moyens permettant de contrer les multiples possibilités d’apparier (au moyen de quasi-identifiants ou du NAVS) les données personnelles contenues dans les bases de données. Toutefois, l’introduction d’identifiants sectoriels spécifiques ne serait pas utile à elle seule.

Si l’on entend écarter radicalement les problèmes liés à la protection des données, l’expert conseille de revoir la conception de l’ensemble des bases de données. Les données personnelles et les données factuelles devraient être enregistrées dans des bases de données séparées. De plus, les données personnelles devraient y être exemptes de redondances. Il y a redondance dans les informations lorsque des données ayant un contenu informatif identique figurent plusieurs fois. Des attributs tels que le nom, le prénom ou le NAVS d’un assuré devraient n’être enregistrés que dans une seule base de données. L’appariement des données personnelles avec les données factuelles ne devrait être possible qu’au moyen de « tables de liens » (linkage tables) spéciales, gardées secrètes.

Une telle révision de la conception des bases de données ne remettrait pas fondamentalement en question l’échange de données. Cependant, les attributs ne pourraient plus être enregistrés de manière décentralisée et l’accès aux données devrait toujours passer par la base de données centrale contenant ces attributs. Cela aurait pour effet d’intensifier le trafic de réseau et d’augmenter le nombre d’accès à ces bases de données, et ainsi d’accroître le risque d’erreurs. Les bases de données constitueraient des goulets d’étranglement et des systèmes critiques qui devraient rester constamment disponibles. Concevoir et mettre en œuvre cette nouvelle architecture constituerait une lourde tâche impliquant des frais très élevés pour la Confédération, les cantons et les communes. En effet, comme l’a montré l’expérience du bug de l’an 2000, de petites modifications dans le format des données et la manière d’enregistrer et de traiter les données peuvent déjà avoir un impact considérable sur les coûts. Par ailleurs, l’élimination des redondances peut aussi entraîner des difficultés pour la gestion opérationnelle des bases de données concernées : sans redondances, il serait plus difficile de reconnaître et de corriger les erreurs éventuelles commises par les utilisateurs dans la saisie ou le traitement des données. Si l’on élimine les redondances, il n’est pas possible d’accéder à des copies redondantes en cas de perte de données. On est alors encore bien plus tributaire des backups que d’ordinaire. De plus, l’absence de redondances rendrait difficiles les tests de cohérence, aucune comparaison n’étant possible avec d’autres bases de données (redondantes). Une prescription suivant laquelle la proposition de l’expert devrait être mise en œuvre partout entraînerait donc de nombreux désavantages et des frais élevés. Certes, pour des groupes d’utilisateurs fermés – dans le domaine de la santé par exemple –, il peut tout à fait être judicieux de prévoir, dans des cas particuliers, une architecture impliquant une gestion minimale des données au moment de la création d’une nouvelle base de données. Mais cela n’a de sens que si une telle nouvelle structure peut être mise en place d’un coup pour l’ensemble d’un grand groupe d’utilisateurs. Dans tous les autres cas, on se contente de créer de nouvelles bases de données isolées, ou l’on complète les bases de données existantes par de nouveaux attributs. Pour toutes ces raisons – difficultés opérationnelles et faible plus-value d’un côté, coûts élevés de l’autre –, le présent projet évite d’exiger des acteurs utilisant systématiquement le NAVS qu’ils revoient de fond en comble l’architecture de leurs bases de données. Cependant, même si une prescription générale n’est pas inscrite dans la loi, ces acteurs resteront libres d’adapter cette architecture suivant la proposition de l’expert.

1.3.2.2 Procédure d’autorisation

L’option de mettre en place une procédure d’autorisation pour les acteurs utilisant systématiquement le NAVS a également été examinée. Dans un tel dispositif, le droit d’utiliser systématiquement le NAVS serait accordé par voie de décision par l’autorité compétente. Celle-ci devrait examiner dans chaque cas si le requérant est en mesure d’assurer la protection des données et la sécurité de l’information lors de cette utilisation. L’autorité requérante devrait notamment prouver qu’elle est en mesure de prendre toutes les mesures techniques et organisationnelles requises. L’autorité qui accorde l’autorisation devrait en outre vérifier au moyen de contrôles périodiques procédant par échantillonnage auprès des titulaires d’autorisation si ces derniers remplissent toujours les conditions d’octroi et s’ils respectent l’obligation de diligence et celle de collaborer. Un tel système ne pourrait toutefois être mis en place qu’au prix d’une augmentation des charges administratives et en particulier de frais élevés sans commune mesure avec le bénéfice supplémentaire qui pourrait en résulter, d’autant que les systèmes informatiques sont soumis par nature à des changements constants et que l’octroi de l’autorisation ne pourrait se faire que sur la base de la situation à ce moment précis. Étant donné qu’il est reconnu que les autorités fédérales, cantonales et communales font preuve d’un grand respect de la loi, il convient d’éviter de mettre en place des mécanismes de contrôle et de surveillance dispendieux et de miser plutôt sur le principe de l’autocontrôle.

1.3.2.3 Numéros sectoriels

Dans un système fonctionnant avec des identificateurs sectoriels de personne coordonnés, plusieurs identifiants seraient attribués à chaque personne physique à enregistrer. Chacun de ces identifiants ne pourrait être utilisé que dans le domaine d’activité du secteur administratif concerné, par ex. le secteur fiscal ou celui des assurances sociales. Pour qu’une communication électronique efficace puisse tout de même être établie entre deux services administratifs relevant de secteurs différents, un serveur central d’identification et de communication serait indispensable. Dans la structure actuelle de l’administration, de tels secteurs n’existent pas. Il faudrait donc commencer par les créer. À l’occasion de la consultation de 2004 sur le projet de loi SPIN, la plupart des cantons et des organisations a estimé qu’en ce qui concerne la cyberadministration, une sectorialisation serait trop complexe et coûteuse, qu’elle serait en plus source d’erreurs et qu’elle ne constituait par conséquent pas une solution praticable. Du point de vue actuel, une obligation générale d’introduire des identificateurs sectoriels de personne ou d’autres identifiants similaires représenterait pour de nombreuses autorités fédérales, cantonales et communales un retour en arrière, celles-ci ayant déjà pris des mesures et consenti des investissements dans la certitude que la réglementation actuelle (avec le NAVS comme identificateur de personne univoque pour les autorités) serait maintenue. Dans ces circonstances, la mise en place d’un vaste