6,8 millions de dossiers patients revendiqués — les 3 trous que j’ai trouvés chez nos clients santé

Jeudi 20 août, peu après 6 heures du matin, une publication sur un forum spécialisé revendique l’exfiltration complète de la base d’Alaxione, éditeur français spécialisé dans la prise de rendez-vous et la gestion de la relation entre patients et professionnels de santé. Le volume annoncé donne le ton : 6 835 489 enregistrements utilisateurs, 10 145 988 rendez-vous, environ 18 millions de lignes pour 12,8 Go de données.

Nous avons passé la journée non pas à commenter l’incident, mais à reprendre un par un les dossiers de sous-traitance de nos clients du secteur santé. Trois défauts sont ressortis, toujours les mêmes. Aucun ne concernait le pare-feu, l’antivirus ou le chiffrement. Les trois concernaient des documents que tout le monde croyait à jour.

Les faits : ce que revendique la publication du 20 août

L’auteur de la publication affirme détenir l’intégralité de la base de production. Les structures de tables diffusées en accompagnement décrivent un ensemble particulièrement large : noms, prénoms, coordonnées, dates de naissance et adresses, profession, médecin traitant, champs de numéro de Sécurité sociale, coordonnées bancaires IBAN et BIC, identifiants de compte et informations techniques, dates, heures, lieux et statuts de rendez-vous, et enfin des correspondances médicales avec expéditeur, destinataire, objet et contenu.

Deux tables de discussions sont mentionnées, pour 144 310 et 129 729 entrées, ainsi que 4 202 enregistrements liant praticiens et consultations. Un échantillon de 1 000 lignes a été diffusé pour appuyer la revendication. Le chiffre qui circule le plus est celui des 70 000 numéros de Sécurité sociale présents dans le lot. L’auteur indique par ailleurs avoir prévenu l’éditeur environ deux jours avant de rendre l’affaire publique.

Un point de méthode s’impose ici, et nous le posons avant toute analyse : à l’heure où nous écrivons, il s’agit d’une revendication. Ni l’éditeur ni la CNIL n’ont publié de confirmation. Les volumes annoncés par un attaquant sont fréquemment gonflés, les échantillons parfois recomposés à partir de fuites antérieures. Le traitement journalistique correct consiste à écrire « revendiqué », pas « volé ».

Pourquoi une base de rendez-vous vaut plus qu’un fichier client

La réaction spontanée, face à une base de prise de rendez-vous, consiste à minimiser : « ce ne sont que des créneaux horaires ». C’est faux, et la structure des tables le montre bien. Le champ décisif n’est pas l’identité, c’est le motif de consultation associé à la spécialité du praticien. Une date, un nom et un service d’oncologie constituent une donnée de santé au sens de l’article 9 du RGPD, même si aucun compte rendu médical n’a été exfiltré.

Le deuxième champ décisif est le numéro de Sécurité sociale. Un mot de passe se change en trente secondes, une carte bancaire se fait réémettre en trois jours. Un numéro de Sécurité sociale accompagne une personne toute sa vie. Associé à une date de naissance et à une adresse, il permet des ouvertures de droits frauduleuses et des usurpations qui se manifestent parfois des années après la fuite d’origine. C’est la raison pour laquelle nous le représentons en rouge sur le graphique ci-dessus : c’est la seule ligne dont la victime ne peut rien faire.

Le troisième est la présence conjointe d’IBAN et de BIC. Sur un fichier de cette taille, la fraude au virement ne se joue pas au détail : elle se joue en industrialisant des demandes de changement de coordonnées bancaires auprès d’organismes tiers, avec un dossier de vérification déjà complet grâce aux autres colonnes. Enfin, les correspondances entre patients et praticiens ouvrent la porte à des campagnes de chantage extrêmement ciblées, parce que l’attaquant connaît le contexte exact de chaque échange.

Le maillon faible n’est pas le cabinet, c’est la chaîne de sous-traitance

Un incident de cette nature ne se produit presque jamais chez le professionnel de santé lui-même. Il se produit un ou deux crans plus loin, chez l’éditeur qui centralise les données de milliers de cabinets, ou chez le prestataire technique de cet éditeur. La jurisprudence française est déjà nourrie sur ce point : la CNIL avait sanctionné le sous-traitant Dedalus après une fuite massive de données de laboratoires, établissant clairement qu’un sous-traitant répond de ses propres manquements de sécurité.

La séquence 2026 confirme la tendance. En janvier, France Travail a écopé de 5 millions d’euros pour n’avoir pas assuré la sécurité des données qui lui étaient confiées. Le 26 mai, la CNIL a prononcé une amende de 5 millions d’euros contre Iqvia Operations France sur un dossier touchant précisément aux données de santé. Sur l’année 2025, l’autorité avait déjà clos l’exercice à 486,8 millions d’euros pour 83 sanctions. Le message adressé au marché n’a rien d’ambigu.

Ce qui a changé, c’est le niveau d’exigence technique attendu au titre de l’article 32. La CNIL ne se contente plus d’une politique de sécurité affichée : elle attend le chiffrement des données sensibles en transit et au repos, l’authentification multifacteur sur les accès d’administration, et des tests d’intrusion réguliers. Ces trois éléments sont vérifiables. Ils sont donc opposables.

Les 3 trous relevés chez nos clients santé

Trou n°1 — Le contrat existe, la preuve n’existe pas. Sur les dossiers repris ce jeudi, tous disposaient d’un contrat de sous-traitance conforme dans sa forme. Aucun ne disposait d’un élément de preuve daté de moins de douze mois attestant que le prestataire appliquait effectivement les mesures décrites. Ni rapport de test d’intrusion, ni attestation de certification en cours de validité, ni même un questionnaire de sécurité rempli. La clause existe, le contrôle n’a jamais eu lieu. C’est précisément le schéma que nous détaillons dans notre méthode pour encadrer ses sous-traitants au titre de l’article 28 et de NIS2.

Trou n°2 — Personne ne sait quels champs partent vraiment. C’est le constat le plus dérangeant. Interrogées sur les données transmises à leur plateforme de rendez-vous, les équipes citent en général l’identité, le téléphone et le créneau. En ouvrant les échanges applicatifs réels, nous trouvons presque systématiquement davantage : numéro de Sécurité sociale hérité d’un ancien module de facturation, adresse complète, parfois un commentaire libre saisi à l’accueil qui contient une information médicale. Le périmètre déclaré et le périmètre réel divergent, et c’est le périmètre réel qui fuit.

Trou n°3 — Aucun scénario de notification impliquant un tiers. Les plans de réponse à incident que nous relisons traitent des scénarios internes : rançongiciel, perte de sauvegarde, compromission de messagerie. Presque aucun ne traite le cas « notre prestataire annonce une fuite ». Or c’est le scénario le plus probable, et le plus contraint : le délai de 72 heures court à compter de la connaissance de la violation, et il faut alors produire en urgence une liste de personnes concernées que l’on n’a pas, à partir d’un périmètre que l’on n’a jamais cartographié. Nous recommandons de traiter ce cas comme un exercice à part entière, au même titre que le cadrage du périmètre NIS2.

Ce qu’il faut faire cette semaine, sans attendre la confirmation

Listez vos plateformes qui manipulent de la donnée patient. Prise de rendez-vous, téléconsultation, rappel par message, facturation, questionnaires de pré-consultation. Le nombre réel surprend presque toujours la direction, parce que plusieurs de ces outils ont été souscrits au niveau d’un service et non au niveau de l’organisation.

Pour chacune, écrivez la liste exacte des champs transmis. Pas la liste supposée : la liste observée dans les échanges applicatifs ou dans les exports. C’est une demi-journée de travail et c’est le document qui vous sauvera si vous devez notifier dans l’urgence.

Demandez une preuve de sécurité datée à chaque prestataire. Un rapport de test d’intrusion de moins de douze mois, avec le périmètre et le plan de correction. Le délai et la qualité de la réponse valent audit à eux seuls.

Révoquez ce qui traîne. Comptes de prestataires historiques, clés d’interface applicative sans date d’expiration, accès de support ouverts « le temps d’une migration » il y a deux ans. La même hygiène s’applique aux chaînes d’intégration continue, un sujet que nos confrères de D-Open documentent régulièrement côté développement, et aux connecteurs de plateformes d’IA qui aspirent des bases métier entières, un angle couvert par Plug-Tech.

Que la revendication du 20 août se confirme ou non, le calcul reste le même. Une plateforme qui concentre les rendez-vous de plusieurs millions de patients est une cible dont la valeur ne cesse de croître, et la seule variable que vous contrôlez vraiment est le volume de données que vous lui confiez.