L’autorisation qui a exposé une nation

Un État peut déléguer l’accès aux données de ses citoyens. Il ne peut pas déléguer sa responsabilité pour ce que cet accès rend possible.

Date de clôture des recherches : 9 octobre 2026. L’enquête pénale et l’examen de l’autorité de contrôle sont en cours. Sauf mention contraire, les chiffres sont des ordres de grandeur.

1. La facture

Le premier signal visible n’a pas été la photo d’un intrus cagoulé. Ce fut une facture.

Le soir du 2 octobre 2026, l’administration du registre central des personnes du Danemark a remarqué une activité inhabituelle remontant à septembre. Les responsables ont ensuite décrit l’indice : un montant bien plus élevé que prévu pour des consultations passées par le compte d’une petite entreprise danoise. L’accès commercial au registre est facturé à la requête. Le volume était devenu trop voyant pour passer inaperçu.¹²

Trois jours plus tard, les autorités du pays expliquaient qu’un tiers non autorisé avait utilisé l’accès légal de l’entreprise pour obtenir des données concernant environ 8,8 millions de personnes. L’accès de l’entreprise a été coupé. La police et l’autorité de protection des données se sont saisies de l’affaire.³¹⁴

Le titre évident s’écrit tout seul : un pays mis à nu par un mot de passe. Mais ce n’est pas encore l’histoire établie. Le 9 octobre, une personne anonyme a affirmé à Politiken qu’un mot de passe aussi faible que 123456, lié à un ancien employé de l’entreprise et déjà présent dans une fuite antérieure, avait ouvert la voie. Un article relayant l’enquête de DR a bien retrouvé un tel mot de passe dans une fuite liée à l’entreprise, tout en soulignant que son usage dans cet incident précis n’était pas confirmé.⁵⁶

L’allégation se vérifiera peut-être. Elle devra peut-être aussi être sérieusement revue quand les éléments forensiques seront connus. Le fait le plus solide est déjà public : l’activité suspecte est passée par une connexion professionnelle autorisée.³¹

Voilà l’architecture de cette histoire. Le registre n’a pas eu besoin de disparaître. L’État n’a pas eu à perdre toutes ses bases de données. Il a suffi d’un seul chemin autorisé, par lequel un attaquant a pu faire bien plus que ce pour quoi l’autorisation avait été accordée.

Une porte légitime a servi à une opération d’une ampleur illégitime.

2. Ce que signifient 8,8 millions – et ce qu’ils ne signifient pas

Le CPR n’est pas un coffre à mots de passe pour tous les services publics. C’est le système central d’état civil et de population du Danemark. Ses données servent à identifier et à administrer, y compris dans les échanges avec les services publics comme avec le secteur privé.³¹⁷

Parmi les catégories dont l’accès est confirmé figurent les noms, les adresses, les numéros CPR et d’autres informations que les autorités ne décrivent qu’en termes généraux. La liste exacte des champs n’est pas établie publiquement dans les sources examinées. Selon les autorités, l’accès ne portait pas sur les noms et adresses des personnes protégées par le dispositif danois de protection du nom et de l’adresse. C’est plus étroit que de dire que ces personnes n’ont été exposées dans aucun champ, ni d’aucune façon.³¹

Le gouvernement a indiqué que le CPR comptait environ 11 millions de personnes enregistrées, y compris, explicitement, celles qui ont quitté le Danemark et les personnes décédées. Rapporter les 8,8 millions de fiches concernées à la population résidente actuelle gonflerait artificiellement la proportion. Et affirmer que la fuite touche « tous les Danois » ferait d’un incident déjà énorme une fausse statistique.¹

Il s’agit d’une atteinte à la confidentialité : quelqu’un a obtenu des informations qu’il n’était pas en droit de recevoir. Rien dans les informations publiques n’établit que le registre central a été détruit, que des données ont été effacées de façon irréversible, ni que les bases fiscales, médicales, bancaires et policières ont toutes été siphonnées.³⁴

Cette précision n’est pas une politesse rédactionnelle. L’exagération rend la reddition de comptes plus difficile. Autorités, fournisseurs, responsables politiques et ingénieurs en sécurité doivent répondre du mécanisme qui a réellement failli – pas d’un effondrement total imaginaire.

3. Un accès autorisé, une opération qui ne l’était pas

Le Danemark permet à certaines organisations privées d’obtenir des informations définies du CPR, dans un cadre légal. L’article 38 de la loi sur le CPR prévoit le droit de recevoir des informations sur un groupe défini de personnes préalablement identifiées individuellement, à des conditions fixées par la loi. Les termes exacts de l’accord d’accès de cette entreprise n’ont pas été publiés dans les sources examinées.⁷

Avoir le droit de consulter une fiche n’équivaut pas à avoir le droit de constituer un fichier à l’échelle d’une population.

Au niveau d’une seule requête, la différence peut sembler anodine. Un client agréé présente des identifiants valables. Une application demande une fiche. Le registre renvoie ce que les droits du client permettent. Aucune frontière visible n’a été franchie.

Répétez l’opération des millions de fois, et la question de sécurité change de nature. Ce qui était proportionné pour vérifier un client devient une extraction à l’échelle nationale. Un contrôle qui décide seulement si une organisation peut accéder à un champ ne décide pas pour autant si une suite donnée de requêtes est légitime dans son contexte.

L’autorité de contrôle a indiqué que des consultations automatisées avaient été effectuées pour identifier des numéros CPR valides. Des articles fondés sur la notification évoquent environ 14 millions de recherches – bien au-delà de la clientèle de l’entreprise –, que l’entreprise nie avoir lancées.⁴⁸

La voie d’entrée présumée, par des identifiants, compte pour les mesures correctives. Elle soulève des questions sur les départs du personnel, la robustesse des mots de passe, la rotation des comptes, l’authentification multifacteur, la surveillance des identifiants et l’accès à distance. Mais cela doit rester des questions d’enquête, pas un verdict déguisé sur les protections qui étaient ou non en place. Les sources publiques n’établissent ni la chaîne d’authentification complète, ni les systèmes internes traversés, ni la manière dont les données ont été transférées à l’extérieur.⁵⁶

Même si l’on découvre au bout du compte une faille compliquée, la question de fond demeure : un tiers a pu déclencher un nombre extrême d’opérations d’apparence légitime avant que l’accès ne soit coupé.

Une autorisation est un point de départ. Ce n’est pas un modèle de sécurité complet.

4. Une souveraineté qui se joue contre la montre

La chronologie compte au moins autant que l’ampleur.

Selon le communiqué officiel du ministère, l’administration a remarqué les irrégularités de septembre le 2 octobre ; l’autorité de contrôle confirme avoir reçu la notification le 4 octobre, et le gouvernement a rendu l’incident public le 5 octobre.¹⁴

Des informations publiées le 9 octobre indiquent que la fenêtre d’accès non autorisé s’est étendue du 10 septembre au 2 octobre, soit environ 21 jours et 17 heures. Selon le compte rendu préliminaire de l’enquête, l’exploitation effective a eu lieu du 10 septembre jusqu’aux alentours du 20 septembre. Ce sont deux intervalles distincts : l’accès restait possible ne veut pas dire aspiration continue confirmée.⁸

Le pirate, de son côté, affirme être entré le 11 septembre. Cet écart n’est pas résolu. Pour la chronologie, la version de la fenêtre d’accès rapportée par la presse d’après la lecture par TV 2 d’une notification réglementaire – et non une publication officielle – prévaut ; la date avancée par la personne anonyme est mentionnée, mais pas fondue en silence dans la frise.⁸⁵

Un État peut posséder ses systèmes, fixer les autorisations légales et poursuivre les accès non autorisés. Mais un élément décisif du contrôle opérationnel est le temps : l’intervalle entre l’abus, sa détection, la décision et la révocation effective.

Reprenons la séquence. Les consultations suspectes auraient cessé vers le 20 septembre. La révocation est intervenue le 2 octobre. Même si aucune donnée supplémentaire n’a été prise entre-temps, l’accès apparemment exploitable a survécu à la principale phase d’aspiration.⁸

La détection n’est pas seulement une affaire de sécurité informatique ; c’est un exercice d’autorité. Avant de pouvoir retirer une autorisation, le gestionnaire d’un registre doit savoir qu’elle est détournée. Un droit d’intervenir qui ne s’exerce qu’après quinze jours d’extraction silencieuse est plus faible qu’il n’en a l’air sur un organigramme.

Ce constat rejoint une idée qui traverse cette Bibliothèque : la souveraineté est opérationnelle, et la souveraineté opérationnelle se mesure au chronomètre. Cela ne signifie pas que chaque incident prouve qu’un État manque de souveraineté. Cela signifie qu’il faut confronter les prétentions de contrôle au temps réellement nécessaire pour détecter un abus, décider et le contenir.⁹

5. L’identifiant qui survit à la fuite

Un numéro CPR identifie une personne. Il ne devrait pas servir de secret réutilisable, censé prouver que la personne qui le présente est bien celle à qui il appartient.

La distinction paraît élémentaire. L’identification demande : De quelle fiche parlons-nous ? L’authentification demande : Qu’est-ce qui prouve que cette personne contrôle un authentifiant valable pour cette identité ? Les référentiels modernes d’identité numérique font de cette différence un fondement. Un identifiant est ce qu’une session authentifiée peut affirmer ; à lui seul, ce n’est pas un facteur d’authentification suffisant.¹⁰

L’affaire danoise montre pourquoi c’est important. La diffusion massive de numéros stables peut faire baisser le coût de l’usurpation d’identité partout où une entreprise confond encore la connaissance d’une fiche personnelle avec une preuve de légitimité. Après l’incident, une organisation patronale a expressément mis en garde contre l’usage des numéros CPR, des noms et des adresses comme seule vérification de l’identité d’un client.¹¹

Les risques comprennent l’hameçonnage ciblé, l’ingénierie sociale et la fraude contre des services aux contrôles d’identité faibles. Ce sont des scénarios crédibles d’exposition. Ils ne prouvent pas que chaque personne concernée a subi une fraude financière, ni que des numéros CPR volés suffisent à eux seuls pour accéder à MitID ou à des comptes bancaires. On ne devrait pas effrayer les gens avec des affirmations que le mécanisme n’étaye pas.

Il existe aussi une asymétrie tenace. Un mot de passe se réinitialise. Un identifiant administratif est conçu pour rester stable. Même une fois le compte compromis fermé et le périmètre du registre réparé, un jeu de données copié – s’il est conservé – peut continuer à fournir du contexte pour des attaques ultérieures. L’incident a eu une fenêtre d’exploitation courte et des conséquences potentiellement durables.

D’où une question politique difficile. La réponse ne peut pas consister simplement à changer tous les identifiants. Ce serait source de perturbations administratives, sans corriger les organisations qui traitent les identifiants comme des secrets. La priorité la plus défendable est de retirer aux transactions sensibles la confiance accordée au seul identifiant, de renforcer la lutte contre la fraude et de concevoir les futurs justificatifs pour qu’ils ne révèlent que le nécessaire.¹⁰¹¹

6. Le miroir européen

Il serait confortable d’y voir une défaillance purement danoise. Rien n’autorise à supposer que le même modèle d’accès, la même journalisation ou la même faiblesse existent ailleurs ; mais la tension de conception sous-jacente concerne beaucoup de monde.

Les États tiennent des registres qui font foi. Les hôpitaux dépendent de logiciels externes. Les banques s’appuient sur des services d’identité tiers. Prestataires et fournisseurs spécialisés ont besoin d’un certain accès pour faire un travail légitime. Une société numérique mûre compte donc de plus en plus de lisières, où les décisions d’identité et d’autorisation d’une institution deviennent le risque d’une autre.

La question n’est pas de savoir si l’accès de tiers est irresponsable en soi. Les services publics modernes ne peuvent pas fonctionner sans opérations déléguées. La question est de savoir si la délégation est encadrée par la finalité, le volume, le périmètre, la durée et un responsable joignable, capable de l’arrêter.

La Suisse offre un contraste utile – pas une équivalence – en matière de conception de l’identité numérique. Les descriptions officielles de son e-ID et du portefeuille swiyu mettent en avant un partage décidé par l’utilisateur et la minimisation des données. En 2026, le gouvernement suisse a annoncé des mesures supplémentaires : réserver la demande du numéro AVS aux seuls acteurs légalement habilités, obliger les fournisseurs à enregistrer la finalité des attributs demandés, et permettre un avertissement ou une exclusion en cas d’usage abusif. Ces mesures concernent une autre architecture d’identité ; elles ne prouvent ni que les registres suisses sont à l’abri d’une exposition massive, ni que chaque changement annoncé est déjà en service.¹²¹³

Le numéro AVS suisse, comme le numéro CPR danois, est un identifiant administratif permanent régi par un cadre légal propre ; ni l’un ni l’autre ne devrait être assimilé à une preuve cryptographique d’identité.¹⁴

La semaine de la révélation danoise a offert deux mises à l’épreuve suisses bien différentes de cette frontière. Le 9 octobre 2026, dans un communiqué diffusé via EQS à 14 h 01, la maison mère de Ricardo, SMG Swiss Marketplace Group, a annoncé qu’une faille de sécurité avait permis un accès non autorisé à des données personnelles liées à des commandes sur sa plateforme, associées à environ 890 000 comptes d’utilisateurs. Parmi les données exposées figuraient des noms, des adresses postales et des numéros de téléphone, ainsi que, le cas échéant, des raisons sociales. Selon SMG, les adresses e-mail et les mots de passe n’étaient pas concernés, et la faille avait été corrigée. Le communiqué précisait que Ricardo avait informé le Préposé fédéral à la protection des données et à la transparence (PFPDT).¹⁵¹⁶ Dans un article de la SRF publié à 14 h 40 le même jour, une porte-parole de SMG a indiqué à l’agence AWP que les données concernées n’avaient à aucun moment été librement accessibles et qu’aucun accès non autorisé à des données personnelles liées à des commandes sur la plateforme n’avait été constaté. Selon elle, la cyberattaque n’avait jusqu’ici donné lieu ni à une extorsion ni à une demande de rançon.¹⁷ Les deux déclarations figurent ici telles qu’elles ont été rapportées, avec leur heure ; cette édition ne les départage pas. La nature exacte de la vulnérabilité, le chemin suivi par l’attaquant et le sort d’éventuelles copies externes n’étaient pas établis publiquement. C’est un cas de sécurité applicative – pas la preuve qu’un compte de fournisseur autorisé a été détourné à la manière danoise.¹⁵¹⁶

La veille, la Caisse fédérale de pensions PUBLICA avait annoncé, dans un communiqué publié sur les sites de l’administration fédérale, qu’un de ses fournisseurs de logiciels avait été attaqué. Ce fournisseur, PK Softech AG, à Reinach, a déclaré qu’un logiciel malveillant avait permis une intrusion dans une partie de son infrastructure et qu’il fallait partir du principe que des données avaient quitté ses systèmes. PUBLICA a indiqué à ses assurés que des données personnelles avaient probablement fuité, et a cité des informations comme les numéros AVS, les adresses et les données de salaire et de prévoyance qui pourraient être concernées ; ni les données effectivement sorties ni le nombre d’assurés touchés n’étaient établis. C’est la comparaison structurellement la plus proche : le périmètre dans lequel une institution publique traite ses informations s’étendait jusque dans l’environnement d’un fournisseur privé. Contrairement au cas danois, rien n’établit toutefois un détournement de droits légaux de consultation d’un registre de population.^18192021 La dernière partie de ce chapitre suit plus loin cette relation fournisseur.

Il ne faut pas fondre ces trois affaires en une prétendue campagne ou une faille commune. Leur leçon commune est plus exigeante : des données peuvent quitter leur public légitime par plus d’une voie – une autorisation défaillante, un fournisseur compromis ou une vulnérabilité applicative. Souveraineté et bonne garde doivent tenir à chaque frontière, pas seulement à celle qui figure sur l’organigramme d’une administration.

Le défi de l’Europe ne consiste pas simplement à placer davantage de données dans des centres de données nationaux. La localisation peut compter pour la juridiction et la résilience, mais une base de données souveraine peut toujours être détournée par un intermédiaire autorisé relevant de la même juridiction. Ni la localisation ni la propriété ne prouvent à elles seules le contrôle opérationnel.

Un test utile se place du côté de l’adversaire : Que peut faire le plus petit client légitime avec les droits que nous lui avons donnés, à la vitesse maximale que permet son logiciel, avant que quiconque ait le pouvoir de l’interrompre ?

Si la réponse englobe une part significative d’un registre national de population, le problème tient autant à la conception de l’autorité déléguée qu’à la sécurité du client.

PUBLICA : quand une relation fournisseur devient une frontière de sécurité commune

Hors du monde de la prévoyance, PK Softech AG est peu connue ; son logiciel tourne pourtant dans de nombreuses caisses de pension suisses. L’entreprise, établie à Reinach (Bâle-Campagne), développe et entretient PK/S, un système central qui gère dans un même outil les assurés actifs et les rentiers, ainsi que des produits complémentaires comme le portail des assurés PK/S.Live.²² En 2017, au terme d’un appel d’offres public, PUBLICA lui a attribué le marché de son application de prévoyance : environ 12,6 millions de francs pour la licence, la mise en service, la migration, la maintenance et le support, sur une durée d’exploitation pouvant atteindre 16 ans.²³

Selon ses propres termes, PK Softech a été attaquée fin septembre. Des inconnus ont utilisé un logiciel malveillant pour accéder à une partie de son infrastructure informatique ; l’environnement touché aurait été aussitôt déconnecté du réseau, des spécialistes externes appelés et une plainte pénale déposée. Selon PUBLICA, le Ministère public de la Confédération a ouvert une enquête. Depuis le 2 octobre, PK Softech se dit de nouveau « pleinement disponible » pour ses clients.¹⁹¹⁸

Une fuite chez le fournisseur, une question ouverte chez le client. Deux déclarations doivent rester distinctes. La première concerne le fournisseur : le 8 octobre, PK Softech écrivait qu’il fallait partir du principe que des données avaient quitté ses systèmes ; plus tard le même jour, elle évoquait une « fuite de données confirmée » depuis sa propre infrastructure informatique, « et non depuis les systèmes de nos clients », en précisant que l’on examinait si des données de clients étaient concernées.¹⁹²⁰ La seconde concerne le client : PUBLICA a indiqué à ses assurés que des données personnelles avaient probablement fuité et que l’analyse des données effectivement sorties se poursuivait. Pourraient être concernés le nom, le prénom, la date de naissance, le numéro AVS, l’adresse, les numéros de téléphone et adresses e-mail professionnels et privés, les données de prévoyance comme le salaire, le gain assuré et l’avoir de prévoyance, l’état civil ainsi que les données concernant le conjoint ou le partenaire. La page d’information de PUBLICA ajoute l’IBAN, que l’e-mail aux assurés ne mentionne pas.²⁴ À fin 2025, PUBLICA comptait environ 70 000 assurés actifs et 41 600 rentiers.²¹ Ces chiffres décrivent la caisse, non le nombre de personnes touchées, qui n’a pas été rendu public.

Le réseau. Cinq autres institutions de prévoyance sont attestées comme clientes du même fournisseur. La Caisse de pension Migros et la Caisse de pension Poste obtiennent de PK Softech un logiciel de gestion des données des assurés ; toutes deux vérifient encore si leurs données pourraient être concernées. La caisse de la Poste précise que ses données chez PK Softech sont anonymisées et que des données particulièrement sensibles, comme les dossiers AI, n’y sont pas stockées.²⁵²⁶ La Caisse de pension bernoise (CPB) et la Caisse d’assurance du corps enseignant bernois (CACEB) mentionnent un fournisseur externe de logiciels, selon la CPB la même entreprise que celle de PUBLICA. Selon le canton de Berne, rien n’indique que des données des deux caisses aient été dérobées, sans que cela puisse être totalement exclu.²⁷²⁸²⁹ La Caisse de pension Syngenta exploite un portail des assurés PK/S.Live que PK Softech met à disposition et entretient ; aucune communication de Syngenta sur l’incident n’a été trouvée au 10 octobre.³⁰ Une liste de clients n’est pas une liste de victimes. À la clôture des recherches, aucune fuite des données de ces caisses n’était confirmée.

Pourquoi des caisses fédérale, cantonales et d’entreprise partagent une même dépendance. Une caisse fédérale, deux établissements cantonaux et trois caisses d’entreprise ont des fondateurs et des assurés différents. Ils partagent le travail administratif du deuxième pilier, que, selon PK Softech, l’on accomplit le plus souvent avec des solutions standard proposées en Suisse par environ 15 fabricants.²² Acheter une telle solution, c’est partager un fournisseur avec d’autres. Cela ne prouve ni la même version, ni le même lieu d’hébergement, ni les mêmes accès d’administration, ni la même faiblesse de sécurité. Produit commun, fournisseur commun, hébergement commun, infrastructure commune, accès d’administration commun et défaillance commune sont six constats différents. Les sources publiques établissent le fournisseur commun et, comme lieu de l’attaque, l’infrastructure propre de ce fournisseur.

Des déclarations différentes, des degrés de certitude différents. Le communiqué de PUBLICA était titré « fuite de données confirmée », mais son texte précisait que l’on examinait encore dans quelle mesure des données de PUBLICA étaient concernées.¹⁸ PK Softech a écrit que ses systèmes de test ne contiennent « en principe » pas de données en clair, sans dire si l’environnement touché était un système de test.²⁰ Le directeur de la CPB a rapporté à Keystone-ATS que, selon l’éditeur du logiciel, une quantité de données plutôt faible avait fuité, peut-être des données commerciales sans lien avec les dossiers des assurés.³¹ Ces déclarations sont posées ici côte à côte ; elles ne sont pas compensées l’une par l’autre.

Rétablir le service n’est pas rétablir la confidentialité. « Pleinement disponible » décrit la disponibilité. La phrase de PUBLICA « Votre avoir de prévoyance est en sécurité » concerne l’intégrité des avoirs et des paiements.²⁴ Aucune des deux ne dit si des copies de données personnelles se trouvent entre d’autres mains. Un fichier sorti ne revient pas parce qu’on rallume le serveur.

Qui tient le registre des données détenues par le fournisseur ? Pour chaque caisse, la question n’est pas de savoir si elle utilise un logiciel sous licence, mais quelles données se trouvent chez le fournisseur, sous quelle forme, dans quel but et pour combien de temps : support, migration ou tests. Les termes ne sont pas interchangeables. Des données correctement anonymisées ne peuvent plus être rattachées à personne. Des données pseudonymisées portent un code à la place du nom ; qui détient la clé ou assez d’informations complémentaires peut remonter à la personne. Des données chiffrées ne sont protégées que dans la mesure où leurs clés le sont. Que « anonymisées » vaille au sens strict pour la caisse de la Poste ne peut être vérifié à partir de sources publiques. Pour le marché de PUBLICA de 2017, l’objet, les prestations et la durée sont publics ; le cahier des charges, les exigences de sécurité, les accès du fournisseur, d’éventuels sous-traitants, les droits d’audit et les obligations de notification en cas d’incident ne le sont pas.²³ Rien de cela n’établit une négligence de quiconque. Cela montre combien peu les assurés ou une autorité de surveillance pourraient vérifier aujourd’hui.

7. Ce qu’exigerait une architecture de contrôle défendable

Aucun interrupteur unique ne répare ce type de défaillance. Une réponse crédible comporte plusieurs couches.

Authentifier l’opérateur. Vérifier l’identité des systèmes et des administrateurs humains, tenir un inventaire des identifiants, retirer vite les accès des personnes qui partent et exiger, là où c’est techniquement possible, une authentification multifacteur ou cryptographique adaptée. Traiter le mot de passe faible signalé comme une question d’enquête – pas comme une cause universelle démontrée.⁵¹⁰

Lier l’accès à une finalité. Définir pour chaque client la raison d’affaires, les fiches autorisées et les opérations permises. La simple appartenance à une organisation ne devrait pas conférer un pouvoir de consultation illimité. Réexaminer les exceptions et soumettre les gros volumes à une approbation explicite. Il s’agit d’une proposition d’architecture de contrôle, pas d’une affirmation sur la conception actuelle exacte du CPR.

Observer le comportement cumulé. Surveiller le rythme des requêtes, le nombre de personnes distinctes renvoyées, les schémas inhabituels de découverte d’identifiants valides, les pics rapportés à la clientèle et les décalages d’horaire. Un million de requêtes valides une à une ne devrait pas ressembler à un million d’opérations de routine indépendantes.

Rendre l’intervention automatique et redevable. Prévoir la limitation de débit, des coupe-circuits gradués, un examen humain urgent, une responsabilité claire pour la révocation et un confinement qui préserve les preuves. Les heuristiques de détection de fraude produiront des faux positifs ; les garde-fous ont donc besoin de seuils transparents et de dérogations vérifiables plutôt que de coupures arbitraires.

Considérer les attributs d’identité comme exposés. Les parties qui s’appuient en aval sur ces données ne devraient pas utiliser des identifiants de type CPR ou la connaissance d’une adresse comme seule authentification. Adopter des authentifiants proportionnés au risque et une vérification des transactions. Les lignes directrices du NIST sur l’identité numérique sont utiles ici, même si elles ne fixent pas de responsabilités juridiques danoises.¹⁰

Produire des résultats vérifiables. Une fois l’incident contenu, publier son périmètre, les catégories de données confirmées, une chronologie soigneusement délimitée, les constats de gouvernance et les mesures correctives que l’on peut décrire sans aider un attaquant. Le Comité européen de la protection des données (CEPD) propose des lignes directrices de référence sur la notification et le traitement des violations de données personnelles ; elles ne préjugent pas de cette enquête.³²

La norme devrait être la preuve, pas le spectacle. Un nouveau tableau de bord ne prouve pas la détection. Un document de politique ne prouve pas la révocation. L’attestation d’un fournisseur ne prouve pas qu’un accès anormal sera bloqué à temps. La preuve qui compte est un exercice : peut-on détecter et contenir l’abus simulé d’un compte légitime avant qu’il ne devienne une exportation à l’échelle d’une population ?

8. La question du darknet – et les limites de cette édition

À la date de clôture de cette édition, le 9 octobre 2026, l’examen des sources publiques n’a relevé aucune annonce publique sur le darknet, vérifiée de manière indépendante, proposant l’ensemble des données du CPR. Ce n’est pas un certificat de sécurité pour les données. C’est simplement la limite de ce qui pouvait être vérifié.

La personne anonyme a dit aux journalistes qu’elle n’avait pas l’intention de vendre ni de publier les numéros. Elle aurait remis un échantillon ou un fichier à Politiken, qui a soumis du matériel à un expert ; cela donne du poids à l’affirmation selon laquelle elle détient les données, mais rien sur son motif, sur l’exclusivité des copies ou sur sa capacité à empêcher une diffusion ultérieure.⁵

Nous n’avons pas acheté de données volées, pénétré de marchés criminels privés, interrogé l’auteur présumé, examiné les preuves conservées par les enquêteurs ni assuré une veille continue des fuites. Nous ne pouvons donc pas établir si un échange privé a eu lieu. L’état honnête des connaissances est le suivant : collecte des données fortement étayée ; vente publique sur le darknet non confirmée ; diffusion ultérieure non élucidée.

La tentation de combler ces lacunes par des certitudes est compréhensible. C’est aussi exactement ainsi que l’analyse d’un incident se transforme en commentaire peu fiable.

9. Qui détient les clés d’une nation ?

L’incident danois ne prouve pas que les registres centraux ne devraient pas exister. Il prouve que le périmètre de sécurité d’un registre dépasse les serveurs sur lesquels il tourne.

Ce périmètre comprend l’entreprise autorisée à l’interroger, l’ancien employé dont le compte figure peut-être encore dans une base, l’accord commercial qui mesure l’usage, l’équipe de sécurité qui interprète les schémas, le fonctionnaire habilité à retirer l’accès, et les institutions qui traitent ensuite un numéro d’identification permanent comme s’il était un secret.

Chacun de ces liens est une relation d’autorité. Chacun peut céder à une vitesse différente.

Nous devrions finir par disposer d’un meilleur dossier forensique : qui a obtenu l’accès, comment il s’est authentifié, quelles données il a conservées et si le matériel copié a jamais circulé. Ces constats pourront changer des détails du récit. Ils ont peu de chances d’effacer la question d’ingénierie centrale : comment l’autorisation d’effectuer une consultation ordinaire est-elle devenue la capacité concrète d’obtenir des fiches sur des millions de personnes ?

La souveraineté numérique ne peut pas s’arrêter à la possession de la base de données. Elle doit s’étendre aux autorisations, aux comportements, à la surveillance, au processus de révocation et aux hypothèses d’identité de chaque système qui s’appuie sur son contenu.

L’État peut tenir le registre. Le risque loge dans chaque porte qu’il autorise.

Sources