Une erreur informatique mène à l'effacement de 11 ans d'historique de consultation des dossiers de maternité de l'hôpital NUH

C'est la conséquence de l'exécution d'un script SQL configuré pour un autre hôpital

Le Nottingham University Hospitals NHS Trust (NUH) est l'un des plus grands services hospitaliers universitaires du système de santé public britannique (NHS), créé en 2006 par la fusion du Queen's Medical Centre et du Nottingham City Hospital. Une erreur informatique a mené à l’effacement de onze années d’historique de consultation de ses dossiers de maternité. L’incident vient mettre en lumière les dangers de l’exécution de scripts automatisés configurés pour un autre hôpital.

BREAKING: Nottingham University Hospitals NHS Trust has released a statement admitting to the loss of maternity data.

Lead UK presenter @skysarahjane and Health Correspondent Ashish Joshi have the latest.

🇬🇧 The UK Tonight: https://t.co/CzjMiOz59M

📺 Sky 501 and YouTube pic.twitter.com/RBVG8b7YiZ

— Sky News (@SkyNews) September 21, 2026

Erreur informatique du NUH : Ce qui est définitivement perdu, ce qui a été sauvé

L’incident s'est produit lors de travaux techniques de routine menés par l'équipe informatique de l'hôpital. Une erreur humaine a conduit à l'écrasement accidentel d'une base de données contenant les dossiers de maternité de milliers de femmes et de bébés pris en charge entre septembre 2011 et novembre 2022 (soit 11 ans de données historiques).

Le bilan de la perte de données fait état de ce que l'hôpital a réussi à restaurer l'intégralité des données cliniques essentielles aux soins (notes médicales, observations, résultats d'examens). Les patients actuels n'ont pas été affectés.

Par contre, le département informatique a admis son incapacité à restaurer l'historique d'audit (les logs de consultation) de cette période de 11 ans. Cela signifie qu'il est désormais impossible de savoir qui a consulté ou modifié ces dossiers sur plus d'une décennie.

Cette perte d'historique détruit une part d'imputabilité indispensable, d'autant que l'hôpital a récemment dû licencier plusieurs employés pour avoir consulté de manière illégitime des dossiers médicaux confidentiels.

Nottingham University Hospitals NHS Trust has apologised after 11 years worth of data on mothers and babies was lost. @skysarahjane speaks to a couple whose daughter died shortly after she was born due to care failings.

🇬🇧 Watch The UK Tonight: https://t.co/1rxXT6zhdo pic.twitter.com/4DhGu68ftn

— Sky News (@SkyNews) September 22, 2026

C’est l’utilisation d’un script automatisé SQL conçu pour un autre hôpital qui est à l’origine de cet incident

Un technicien de l'équipe informatique devait dupliquer une base de données de radiothérapie à des fins de reporting et d'analyse. Pour ce faire, le technicien a exécuté un script d'instructions pré-écrites (un script de configuration automatique) conçu initialement pour un autre système hospitalier. Une ligne de configuration ou un paramètre d'identification (la cible de la base de données) devait obligatoirement être modifié avant le lancement de la procédure. Cette modification a été oubliée. Le script s'est donc trompé de cible et s'est exécuté directement sur la base de données principale de la maternité, écrasant ses données avec celles de la radiothérapie.

NHS maternity data lost during routine IT work - tap the pic to read more https://t.co/UhujdhhAlj

— BBC Nottingham (@BBCNottingham) September 22, 2026

L’incident fait suite à des cas similaires récents documentés

Les incidents d'écrasement de bases de données de production ou de pertes massives par erreur de manipulation restent une plaie récurrente pour les directions de systèmes d’information :

• UK Biobank (Mars 2026) : L'une des plus grandes bases de données de recherche médicale au monde a subi une fuite massive de données après de simples erreurs de manipulation de fichiers par des chercheurs, exposant des données de santé en ligne.
• Incident au sein du même Trust (Nottingham - mi-2025) : L'année précédente, un fichier informatique contenant des centaines de cas de maternité liés à l'enquête avait temporairement disparu. L'enquête de la cellule cyber de la police a conclu qu'il s'agissait d'une suppression "intentionnelle ou malveillante" par un individu, et non d'une faille systémique.
• Ministère de l'Éducation Nationale français (Mars 2026) : Une mauvaise isolation/gestion a exposé les données RH (base Compa) de 243 000 agents et enseignants, mettant en ligne des informations personnelles et des historiques d'absences

Quelles leçons pour les départements informatiques ?

Cet incident est un cas d'école des risques liés à l'administration des systèmes critiques. Les DSI sont susceptibles de tirer plusieurs leçons capitales de cette bévue :

• Interdiction de la réutilisation aveugle de scripts : Les scripts critiques (surtout ceux contenant des commandes d'écriture, de suppression ou d'écrasement) ne doivent jamais être réutilisés sans passer par un outil de gestion des configurations (comme Ansible ou Terraform) où les variables d'environnement (Production vs Test, Maternité vs Radiothérapie) sont strictement cloisonnées et automatisées.
• Mise en place de garde-fous et de mécanismes "Fail-Safe" : Avant l'exécution d'un script d'écrasement ou de clonage, le système devrait exiger une validation explicite (par exemple, une invite demandant de retaper le nom exact de la base de données cible).
• Application stricte du principe du double contrôle : Aucune opération de maintenance sur des bases de données de production ou historiques contenant des données sensibles ne devrait être exécutée par un ingénieur seul sans la double validation d'un pair ou d'un administrateur système.
• Sécurisation externalisée et immuable des Logs d'Audit : L'historique d'accès (qui a consulté quoi) est une donnée de sécurité et de conformité légale aussi précieuse que la donnée de santé elle-même. Les fichiers de logs ne doivent pas être stockés dans la même base de données dynamique que celle des patients ; ils doivent être exportés en temps réel vers un serveur de logs centralisé, immuable (Write-Once-Read-Many) et décorrélé des opérations de maintenance courantes.

Source : Annonce du NUH

Et vous ?

Avez-vous été témoin de cas similaires ? Partagez vos anecdotes
Quelles recommandations donneriez-vous aux DSI désireux d’éviter des incidents de ce genre ?

Voir aussi :

France : un pirate accède à la plateforme des impôts et parvient à extraire les données de près de 700 000 usagers, le parquet de Paris a ouvert une enquête

Modifier un chiffre dans une URL pour accéder aux données de 19 millions de Français : le portail de l'ANTS cède face à une vulnérabilité basique. Votre nom, prénom, date de naissance sont peut-être en vente

France Travail sanctionnée d'une amende de 5 millions d'euros pour manquements graves à la protection des données personnelles : la CNIL met fin à l'illusion d'un RGPD à deux vitesses pour le secteur public