Cybersécurité · 21/08/2026

Fuite Alaxione : 6,8 millions de patients revendiqués — et le pirate dit être entré par la préproduction

Un cybercriminel revendique depuis le 20 août 12,8 Go de données extraites de la plateforme française de e-santé Alaxione : 6,8 millions de profils, 10,1 millions de rendez-vous, des messages privés. L'entreprise reconnaît l'intrusion mais parle d'un « serveur de test ». Le point qui départage les versions — une copie de la base de production importée en préproduction — est exactement l'angle mort que partagent des milliers de PME. Ce que dit la CNIL, et les six vérifications à demander cette semaine.

Fuite Alaxione : 6,8 millions de patients revendiqués — et le pirate dit être entré par la préproduction
Cybersécurité
Un cybercriminel affirme depuis le 20 août avoir extrait 12,8 gigaoctets de données de la plateforme française de e-santé Alaxione : 6 835 489 lignes d'utilisateurs, 10 145 988 rendez-vous médicaux et plus de 270 000 messages privés. L'entreprise reconnaît une intrusion mais conteste l'ampleur et parle d'« un serveur de test sans données médicales réelles ». Le détail technique qui départage les deux versions est aussi celui qui concerne le plus directement les PME : une copie de la base de production aurait été importée dans un environnement de préproduction. C'est le genre de phrase que l'on lit vite et que l'on oublie aussitôt. Elle mérite mieux. Dans presque toutes les entreprises qui font développer un site, une application ou un logiciel métier, il existe un double : un environnement de test, de recette ou de préproduction, où l'on essaie les nouvelles fonctionnalités avant de les mettre en ligne. Et dans une proportion considérable de ces cas, ce double contient les vraies données — parce que c'est plus simple, plus rapide, et que « ce n'est pas la production ». L'affaire Alaxione, telle qu'elle est documentée au 21 août par Cyberattaque.org, FrenchBreaches et franceinfo, n'est pas encore établie dans son périmètre exact. Mais elle rend soudain très concret un risque que la CNIL décrit noir sur blanc depuis des années, et que presque personne n'audite : le maillon faible d'un système d'information n'est pas toujours le système lui-même. C'est souvent sa copie.

L'affaire Alaxione en sept repères

  • Alaxione : éditeur français de logiciels de e-santé (agenda médical, prise de rendez-vous en marque blanche, téléconsultation), né à l'initiative d'un ophtalmologiste, membre du pôle de compétitivité Medicen et du réseau French Healthcare.
  • 20 août, 1 h 49 : première publication de FrenchBreaches sur la revendication, signée d'un pseudonyme, « Angel_Batista ».
  • Volumes revendiqués : 12,8 Go, environ 18 millions de lignes réparties en plusieurs tables.
  • Détail des tables : 6 835 489 lignes utilisateurs, 10 145 988 rendez-vous, 144 310 + 129 729 discussions, 4 202 lignes associant praticiens et motifs de consultation.
  • Numéros de Sécurité sociale : environ 70 000 effectivement renseignés selon FrenchBreaches — soit une petite fraction des 6,8 millions de profils.
  • Mise en vente : 5 000 dollars sans exclusivité, soit un peu plus de 4 000 euros.
  • Version de l'entreprise : intrusion confirmée à RTL, mais sur « un serveur de test ne contenant pas de données médicales réelles ».

Ce qui est établi, ce qui est revendiqué, ce qui est contesté

Il faut tenir les trois catégories séparées, parce que l'écart entre elles est, à ce stade, l'essentiel de l'information. Établi : Alaxione a subi une intrusion informatique et l'a confirmé publiquement. Son dirigeant, Patrick Attaiech, a expliqué à franceinfo avoir été informé en début de semaine par un message d'alerte indiquant qu'un de ses serveurs avait été attaqué, puis avoir reçu un lien destiné à négocier l'achat des données — il a refusé toute négociation. L'entreprise a ensuite indiqué avoir mandaté un avocat spécialisé et un expert en cybersécurité pour évaluer l'ampleur réelle du piratage, et annoncé le dépôt d'une plainte. Revendiqué : les volumes. Ils viennent du cybercriminel, qui publie des structures de tables et des captures d'écran pour étayer son propos. FrenchBreaches a examiné ces éléments et décrit une table utilisateurs très riche — noms, noms de jeune fille, adresses électroniques, téléphones fixes, mobiles et professionnels, adresses postales, dates de naissance, professions, médecin traitant, informations d'assurance, adresses IP — assortie de champs explicitement prévus pour un numéro de Sécurité sociale, un IBAN et un BIC. La distinction que fait le site est capitale et rarement rappelée : la présence d'une colonne dans un schéma de base de données ne signifie pas qu'elle est renseignée pour chaque ligne. Sur les 6,8 millions de profils revendiqués, seuls quelque 70 000 numéros de Sécurité sociale seraient effectivement présents. Contesté : la nature des données. Alaxione affirme que l'intrusion a concerné un serveur de test dépourvu de données médicales réelles. Cyberattaque.org, qui s'est procuré un échantillon de 1 000 lignes, écrit que certaines informations « paraissent correspondre à des informations réelles », sans pouvoir extrapoler à l'ensemble. Le média relève aussi que plusieurs adresses électroniques figurant dans l'extrait utilisent des alias — du type +doctolib ou +pointvision — cohérents avec des comptes réellement créés, tout en soulignant qu'un alias ne prouve rien à lui seul. C'est une prudence qui mérite d'être imitée : dans les fuites revendiquées, l'écart entre l'annonce du pirate et la réalité est parfois d'un ordre de grandeur, dans un sens comme dans l'autre.
« Le périmètre exact de l'incident reste contesté. Alaxione reconnaît l'intrusion mais affirme qu'elle concernait uniquement un environnement de test dépourvu de données médicales réelles. » — Cyberattaque.org, 20 août 2026, mis à jour à 16 h 39.

« Préproduction » : le mot autour duquel tout se joue

Les deux versions se rejoignent sur un point : l'environnement touché n'était pas la production. C'est même l'argument central de la défense d'Alaxione. Or les captures publiées par l'attaquant et examinées par Cyberattaque.org montrent une interface d'administration de bases de données — phpMyAdmin — accessible depuis le sous-domaine preprod.alaxione.fr, avec plusieurs bases visibles. L'attaquant, lui, raconte avoir d'abord obtenu des accès à des environnements de développement, puis avoir découvert « une copie temporaire de la base complète importée sur une instance de préproduction ». Si ce récit se confirme, l'incident ne relève pas de l'exploit technique. Il relève de la routine. Une équipe doit tester une migration, une refonte de facturation, un nouveau moteur de recherche ; les jeux de données fictifs ne reproduisent pas les cas tordus de la vraie vie ; alors on duplique la base de production « le temps du test ». La copie est faite un mardi soir. Le test dure trois jours. La copie, elle, reste. Et l'environnement qui l'héberge n'a jamais été durci au même niveau que la production : pas de double authentification, pas de filtrage par adresse IP, un outil d'administration web laissé accessible, des mots de passe hérités du projet précédent. Il n'y a rien de spécifique à la santé dans ce scénario. Un site e-commerce, un logiciel de gestion, un intranet RH, une application de suivi de chantier : dès qu'il existe un environnement de recette, la même tentation existe, et le même angle mort avec elle.
« Fuite massive de données médicales : que faire ? » — Télématin, France Télévisions. Séquence consacrée à une précédente fuite de données de santé française : les réflexes décrits (vigilance au phishing, absence de recours utile après diffusion) valent à l'identique ici.

Ce que dit exactement la CNIL — et la nuance que presque tout le monde ignore

La doctrine française sur ce point existe, elle est publique, gratuite et tient en une page. C'est la fiche « Sécurité : Encadrer les développements informatiques » du Guide de la sécurité des données personnelles de la CNIL, mise à jour le 14 mars 2024. Elle est généralement citée pour sa formulation la plus abrupte, qui figure dans la rubrique « Ce qu'il ne faut pas faire ».
« Utiliser des données personnelles réelles pour les phases de développement et de test. Des jeux fictifs doivent être utilisés autant que possible. » — CNIL, fiche « Encadrer les développements informatiques ».
Sauf que la même fiche, plus bas, dans la rubrique « Pour aller plus loin », dit autre chose de beaucoup plus intéressant — et c'est la phrase qu'aucune PME ne connaît :
« Les tests menés sur les données fictives ou anonymisées ne sont parfois pas suffisants pour s'assurer du bon fonctionnement d'un nouveau service ou d'une nouvelle fonctionnalité. Il est alors possible de tester dans un environnement de pré-production avec des données réelles. L'environnement de pré-production doit être configuré et sécurisé au même niveau que l'environnement de production lui-même et le nouveau service ou sa mise à jour doit avoir déjà subi l'ensemble des tests (unitaires, d'intégration et fonctionnels) dans les environnements de développement et de test. » — CNIL, même fiche.
Autrement dit : la CNIL n'interdit pas la préproduction avec des données réelles. Elle pose une condition, et cette condition est exigeante — même niveau de sécurité que la production. C'est précisément le point où l'affaire Alaxione, si le récit de l'attaquant se vérifie, bascule du côté du manquement. Non pas parce qu'une copie a été faite, mais parce que l'environnement qui l'accueillait n'était manifestement pas protégé comme celui qu'il imitait. Pour approfondir, la CNIL publie également un guide RGPD dédié aux équipes de développement, et une fiche sur l'anonymisation des données personnelles — l'anonymisation véritable faisant sortir les données du champ du RGPD, là où une simple pseudonymisation ne le fait pas.

Les trois régimes possibles, en clair

EnvironnementDonnées admisesNiveau de sécurité attendu
DéveloppementFictivesDistinct de la production ; pas de secret déposé dans le dépôt de code
Test / recetteFictives ou anonymiséesDistinct de la production
PréproductionRéelles possible, si les tests fictifs ne suffisent pasIdentique à la production — c'est la condition, pas une recommandation

Synthèse de la fiche CNIL du 14 mars 2024. Les secrets d'authentification doivent en outre être changés au passage en production.

phpMyAdmin exposé : la deuxième leçon, encore plus banale

L'autre élément technique documenté est un accès à phpMyAdmin. C'est une interface web d'administration de bases de données MySQL ou MariaDB, utilisée dans une immense proportion des hébergements mutualisés français. Elle est pratique, gratuite, et souvent installée par défaut. Elle est aussi, quand elle est laissée accessible depuis l'internet public sans restriction, l'équivalent numérique d'une porte de service ouverte sur la rue avec le trousseau posé dessus : une fois dedans, l'attaquant ne « pirate » plus rien, il consulte et il exporte. Ce n'est pas une nouveauté et ce n'est pas propre à la e-santé. Nous décrivions en juillet une faille critique de WordPress permettant de prendre la main sur un site sans mot de passe, et début août une faille d'administration de serveurs vieille de vingt-deux ans encore exposée par milliers. Le point commun n'est pas la sophistication de l'attaque. C'est l'exposition d'une interface d'administration que personne, dans l'entreprise, n'a jamais eu la responsabilité explicite de fermer. Le guide d'hygiène informatique de l'ANSSI traite cette question depuis sa première édition : cloisonner les réseaux, limiter les interfaces d'administration à des postes et des réseaux dédiés, interdire l'accès à internet depuis les comptes d'administration. Ces mesures sont écrites pour des organisations de toutes tailles. Elles ne coûtent rien d'autre qu'une décision et une demi-journée de prestataire.

Six vérifications à demander cette semaine, même sans équipe informatique

Aucune de ces questions ne suppose de compétence technique. Toutes se posent par écrit à celui qui héberge ou développe votre outil — prestataire, agence, éditeur, freelance. C'est l'écrit qui compte : il vaut réponse, il vaut trace, et il vaut souvent déclencheur.
  • 1. Combien d'environnements existe-t-il pour notre application, et qui les héberge ? Développement, test, recette, préproduction, démonstration, formation : chacun est une copie potentielle. La liste doit être écrite quelque part.
  • 2. Ces environnements contiennent-ils une copie des données réelles ? Question binaire, réponse binaire. Si la réponse est oui, la suivante s'impose.
  • 3. Sont-ils sécurisés au même niveau que la production ? Double authentification, filtrage par adresse IP ou accès via VPN, chiffrement, journalisation, mots de passe distincts de ceux de la production. C'est l'exigence littérale de la CNIL, pas une préférence d'ingénieur.
  • 4. Sont-ils accessibles publiquement ? Les sous-domaines du type preprod., staging., recette., dev. et test. sont les premiers essayés par les outils de reconnaissance automatique. Les interfaces d'administration (phpMyAdmin, Adminer) doivent être fermées à l'internet ouvert.
  • 5. Une copie « temporaire » a-t-elle une date de suppression écrite ? C'est la mesure la moins coûteuse et la plus efficace de toute cette liste : une copie sans date de péremption devient permanente par défaut.
  • 6. Que dit notre contrat de sous-traitance ? L'article 28 du RGPD impose un contrat écrit avec le prestataire qui traite des données pour votre compte. Il peut interdire la duplication de la production hors production sans anonymisation. Si votre contrat est muet, l'avenant tient en trois lignes.

Si la fuite vous concerne comme responsable de traitement

Une violation de données doit être notifiée à la CNIL dans les 72 heures après en avoir pris connaissance, sauf si elle est peu susceptible d'engendrer un risque pour les personnes. Lorsque le risque est élevé — et des données de santé le sont par nature —, les personnes concernées doivent en outre être informées individuellement. La fiche de la CNIL sur les violations de données détaille la procédure ; une analyse d'impact (AIPD) est par ailleurs obligatoire pour les traitements de données de santé à grande échelle.

Le délai de 72 heures court à compter de la connaissance de la violation, pas de sa confirmation complète. Une notification initiale incomplète, complétée ensuite, est prévue par les textes.

Le signalement que personne ne sait traiter

Un détail de l'affaire mérite d'être isolé, parce qu'il se rejouera. L'attaquant affirme avoir prévenu Alaxione environ deux jours avant de rendre l'affaire publique, et n'avoir obtenu aucune réponse. Le dirigeant, de son côté, décrit à franceinfo avoir reçu en début de semaine un message d'alerte signalant qu'un serveur avait été attaqué, puis un lien de négociation qu'il a refusé. Les deux récits ne se contredisent pas nécessairement : ils décrivent une entreprise qui reçoit, un lundi ordinaire, un message anormal — et qui n'a pas de circuit prévu pour le traiter. C'est un manque très répandu. La plupart des PME n'ont aucune adresse publique dédiée aux signalements de sécurité, et un message de ce type atterrit dans un formulaire de contact commercial, où il est pris pour du spam ou pour une tentative d'extorsion. Il existe une réponse simple et normalisée : le fichier security.txt, décrit par la RFC 9116 et documenté sur securitytxt.org. Il s'agit d'un fichier texte déposé à l'adresse /.well-known/security.txt de votre site, indiquant à qui écrire en cas de découverte d'une faille. Il se rédige en cinq minutes. Deux précisions d'honnêteté. D'abord, un tel fichier n'aurait rien changé au vol lui-même. Ensuite, tout signalement n'est pas bienveillant : quand il s'accompagne d'un lien de négociation et d'une mise en vente, on est dans l'extorsion, pas dans la divulgation responsable, et la réponse relève du dépôt de plainte, pas du dialogue. Mais entre l'un et l'autre passe une masse de signalements de bonne foi — un client qui remarque une anomalie, un développeur qui tombe sur un répertoire ouvert — qui se perdent aujourd'hui faute d'une boîte aux lettres.
« Fuite de données médicales : on fait quoi ? » — B SMART. Analyse d'un précédent incident français de données de santé, du point de vue des obligations des entreprises. Antérieure à l'affaire Alaxione, elle en éclaire le cadre juridique.

Pourquoi ce sujet est régional

Les Hauts-de-France ne sont pas spectateurs de la filière santé numérique. La filière régionale Santé-Nutrition animée par Eurasanté et Clubster NSL revendique environ 1 100 entreprises et 32 000 salariés, avec un parc Eurasanté qui regroupe à lui seul plus de 210 entreprises et 3 800 salariés à Lille et Loos — troisième pôle d'excellence santé français. Nous avons décrit ce tissu dans notre panorama des pôles d'innovation du Nord. Une part importante de ces structures édite ou exploite des logiciels manipulant des données de patients. Mais la portée du sujet dépasse largement la santé. Le raisonnement vaut pour toute PME régionale qui a fait développer un outil sur mesure — et la question du double s'y pose exactement dans les mêmes termes. Elle s'ajoute à une séquence dense : la campagne de notification de la DGFiP à 250 000 professionnels, engagée le 17 août, puis la fuite SFR de juillet, alimentent déjà un stock de données personnelles françaises circulant hors de tout contrôle. Chaque nouvelle fuite ne s'ajoute pas : elle se croise avec les précédentes, et c'est le croisement qui fabrique les escroqueries crédibles.

Données de santé françaises : une série continue en 2026

  • 12 mai — CARMF : 2,4 millions d'enregistrements de médecins revendiqués après une cyberattaque.
  • 12 mai — CalendrIDEL : données de 1 400 infirmiers libéraux publiées.
  • 22 mai — Almerys : 15 millions de numéros de Sécurité sociale dans une base attribuée à l'acteur du tiers payant.
  • 2 juin — Mon Espace Santé / DMP : plus de 34 millions de dossiers revendiqués sur le dark web.
  • 9 juillet — Vaccination scolaire en Auvergne-Rhône-Alpes : données d'enfants et numéros de Sécurité sociale exposés.
  • 20 août — Alaxione : 6,8 millions de profils et 10,1 millions de rendez-vous revendiqués.

Chronologie établie à partir des publications de Cyberattaque.org. Les volumes indiqués sont ceux revendiqués par les attaquants et n'ont pas tous été confirmés par les organismes concernés.

Ce qui reste à confirmer

Beaucoup de choses, et il faut le dire clairement. Le nombre de personnes réellement distinctes concernées n'est pas connu — les 18 millions de lignes correspondent à plusieurs tables, et une même personne apparaît dans plusieurs rendez-vous. Le taux de remplissage des champs sensibles (numéro de Sécurité sociale, IBAN, BIC, mot de passe) reste inconnu, de même que le format et la protection cryptographique éventuelle des mots de passe. Le vecteur initial de compromission, la date de la première intrusion et la durée de l'accès ne sont pas établis. Enfin, le rôle exact de l'environnement de préproduction — et la nature des données qu'il contenait — est la question centrale, et elle est précisément celle que l'entreprise conteste. L'attaquant évoque par ailleurs deux compromissions antérieures, en mars 2025 (environ 4 000 lignes) et en novembre 2025 (une petite base SQL). Ces affirmations proviennent de lui seul et n'ont, à ce jour, aucune confirmation indépendante. Si elles se vérifiaient, elles changeraient la lecture de l'affaire : non plus un incident, mais une série. C'est le point à surveiller dans les jours qui viennent, avec les conclusions de l'expert mandaté par l'entreprise et la réaction de la CNIL — que nous avions déjà vue s'exprimer, il y a un mois, sur l'usage des données de santé de Doctolib pour la recherche en IA.

Questions fréquentes

Comment savoir si mes données sont dans la fuite Alaxione ?

Il n'existe à ce jour aucun moyen fiable de le vérifier soi-même, et aucun outil public ne le permet. Alaxione fonctionne largement en marque blanche : ses solutions sont intégrées au site de cabinets et de centres médicaux, si bien qu'un patient peut avoir utilisé la plateforme sans jamais avoir vu son nom. Si le périmètre se confirme et que le risque est jugé élevé, c'est au responsable de traitement d'informer individuellement les personnes concernées, conformément au RGPD. Méfiez-vous par principe de tout site proposant de « tester » votre exposition.

Mon entreprise n'est pas dans la santé : suis-je vraiment concerné ?

Oui, si vous faites développer ou héberger une application, un site marchand ou un logiciel métier. Le mécanisme en cause — une copie de la base de production placée dans un environnement de test moins protégé — n'a rien de spécifique au secteur médical. Il est même plus fréquent dans les structures qui n'ont pas d'équipe informatique interne, parce que personne n'y a la responsabilité explicite de la question.

La CNIL interdit-elle d'utiliser des données réelles en préproduction ?

Non. Sa fiche « Encadrer les développements informatiques » recommande d'utiliser des jeux fictifs ou anonymisés autant que possible, mais prévoit explicitement qu'il est possible de tester en préproduction avec des données réelles lorsque les jeux fictifs ne suffisent pas. Elle y met une condition ferme : l'environnement de préproduction doit être configuré et sécurisé au même niveau que la production, et le service doit avoir déjà passé l'ensemble des tests en amont.

Quel est le délai pour notifier une violation de données ?

72 heures après en avoir pris connaissance, auprès de la CNIL, sauf si la violation est peu susceptible d'engendrer un risque pour les droits et libertés des personnes. Le délai court à compter de la connaissance de l'incident, pas de la fin de l'investigation : une notification initiale partielle, complétée ensuite, est expressément prévue. Lorsque le risque est élevé, les personnes concernées doivent également être informées.

Que faire si l'on reçoit un message signalant une faille sur notre système ?

Ne pas l'ignorer et ne pas y répondre dans l'improvisation. Faites remonter le message à la direction, conservez-le intégralement, ne cliquez sur aucun lien de « négociation » et ne payez rien. Un message accompagné d'une demande d'argent ou d'une mise en vente relève de l'extorsion : il justifie un dépôt de plainte et, si des données personnelles sont en jeu, une notification à la CNIL. Publier un fichier security.txt sur votre site permet, en amont, d'orienter les signalements de bonne foi vers la bonne adresse.

Ce qu'il faut retenir

Le périmètre de la fuite Alaxione sera peut-être revu à la baisse ; il peut aussi être confirmé. Dans les deux cas, la leçon utile est déjà disponible, et elle ne dépend pas de l'issue de l'enquête. Une entreprise protège en général ce qu'elle considère comme son système : le serveur de production, la base client, l'espace de facturation. Elle protège rarement les copies de ce système, parce que les copies n'apparaissent dans aucun inventaire, ne figurent dans aucun contrat, et ne sont la responsabilité de personne en particulier. La question à poser cette semaine à votre prestataire tient en une ligne : « Est-ce que nos environnements de test contiennent une copie de nos données réelles, et sont-ils protégés comme la production ? » Deux réponses possibles, quelques minutes de lecture, et un risque qui cesse d'être invisible.

Sources

⚠ Les volumes cités sont revendiqués par l'auteur de l'intrusion et contestés par l'entreprise. Ils sont rapportés comme tels et n'ont pas été confirmés indépendamment à la date de publication. La déclaration d'Alaxione évoquant « un serveur de test » a été recueillie par RTL et reprise par Cyberattaque.org.

— Fin de l'article · #FUITE-AL · 21/08/2026 —