Covid-19 : des malades égarés au Royaume-Uni à cause d’Excel

Nicolas Furno |

La Public Health England (PHE), l’équivalent de l’agence de la santé publique au Royaume-Uni, a « oublié » 15 874 malades connus dans la semaine du 25 septembre au 2 octobre. Elle a d’abord donné un compte de 50 786 personnes ayant contracté la maladie Covid-19, avant de réaliser son erreur et noter qu’il manquait en moyenne près de 2 000 cas par jour sur cette semaine.

Comment peut-on « oublier » autant de malades en pleine pandémie ? En utilisant les mauvais outils pour gérer les données, évidemment. La PHE est l’organisme qui rassemble les chiffres fournis par tous ceux qui font des tests dans le pays. Les informations sur les malades lui sont transmises sous la forme de fichiers CSV, un format texte qui est effectivement adapté pour transférer de larges quantités de données. L’agence doit ensuite importer ces fichiers dans une base centralisée, mais au lieu de reposer sur un vrai gestionnaire de base de données, comme MySQL ou PostgreSQL, elle utilisait… Excel.

Photo : Christiaan Colen (CC BY-SA 2.0)

Le tableur de Microsoft peut importer des fichiers CSV et vu de loin, on peut le comparer à un logiciel de base de données. Dans les deux cas, les informations sont stockées dans des tables, avec des colonnes qui décrivent le format de chaque donnée et des lignes pour chaque enregistrement. Mais un tableur n’est pas une base de données, ne serait-ce que parce qu’il n’est pas pensé pour stocker de grandes quantités d’informations.

Avec la version actuelle du format de fichier, le .xslx, Excel peut stocker jusqu’à 1 048 576 lignes, ce qui peut sembler beaucoup, mais ce qui est ridicule face à ce qu’une table SQL peut contenir1. Pour ne rien arranger à l’affaire, la PHE utilisait encore l’ancien format de fichiers du tableur, le .xls qui a été créé en 1987 et qui est limité à 65 536 lignes par tableau. Chaque cas était composé de plusieurs lignes, ce qui limitait encore le nombre de cas qu’un tableau pouvait contenir.

En important les données à partir des fichiers CSV — qui n’ont eux aussi aucune limite de longueur, en passant —, l’agence ne conservait sans le savoir qu’une partie des résultats et n’enregistrait pas les suivants. Quand l’erreur a été découverte, le processus d’import a été modifié pour créer plusieurs fichiers et ainsi éviter les limites d’Excel, quel que soit le nombre de cas remontés. C’est bien, utiliser le nouveau format de fichiers d’Excel disponible depuis 2007 serait un petit peu mieux, mais c’est surtout l’outil lui-même qu’il faudrait changer…

La BBC qui rapporte l’information souligne que l’agence a vérifié ses données antérieures et assure que l’erreur n’a commencé que pour la semaine du 25 septembre. Tous les cas oubliés ont été intégrés et pris en charge.


  1. Si vous vous posez la question, la seule véritable limite dans une base de données est l’espace disponible sur l’ordinateur qui sert à la faire tourner. Les performances peuvent poser problème à partir d’un certain nombre d’enregistrements, mais il est possible de stocker plusieurs dizaines de milliards (oui, milliards) de lignes dans une seule table d’une base de données.  ↩︎

avatar pocketjpaul | 

@morpheusz63
" comme quoi l'incompétence existe aussi chez nous"

---

Alors là je tombe des nues

avatar hirtrey | 

@morpheusz63

Mets ta main au feu

avatar Guizilla | 

@hirtrey

+1

avatar hirtrey | 

@morpheusz63

Vas voir le code source de l’application et brûles ta main

avatar rikki finefleur | 

Pour répondre a la plupart des commentaires :
Il est bien connu que lorsque l'on importe des données dans une base de données il n'y a jamais d'erreur .. Non Jamais.. jamais jamais jamais..

Quand a ceux qui disent pourquoi pas de bd ?
Car par exemple tu transmets tes infos et tu envois ta bd avec ?
Non ? Donc tu fais une requête sur ta bd ?
Il est bien entendu que l'on ne fait jamais d'erreur en faisant des requêtes.

Ici c'est juste un pb que l’utilisateur ne connaissait pas la limitation d'excel concernant le nbre de lignes gérées.
Et excel marche très bien avec des imports de csv.
Et l'utilisateur, ce meme utilisateur en triturant une bd aurait pu aussi faire des erreurs.

avatar faya | 

J’ose même pas imaginer la réaction des gens si cela ce serait produit en France

avatar iPop | 

@faya

Parce que les gens « réagissent » ?

avatar switch (non vérifié) | 

Vous n'imaginez pas le nombre d'entreprises ou de "services publics" qui utilisent Excel au lieu d'utiliser un véritable SGBD (petit (FileMaker Pro)) ou grand ( 4D, SQL…).
Les avantages des SGBD sont quand même énormes (y compris pour un particulier fortuné), à commencer par les tables liées et les possibilités d'usage en client/serveur, sans parler de la sécurité…
--
Le service des archives d'un hôpital proche de mon domicile se servait d'Excel comme BDD pour les séjours des patients.
Les personnels flippaient (à raison) à l'idée de faire une erreur.
Ils savaient qu'un simple tri mal réalisé pouvait modifier leur joli tableau: et hop, toutes les données mélangées !
Ils ont changé d'outil depuis: j'espère juste qu'ils n'ont pas repris leur vieux tableau Excel comme point de départ de leur nouvel outil, mais je suis pratiquement certain qu'ils l'ont fait...

avatar marc_os | 

@ swich
« y compris pour un particulier fortuné »

Il n'y a pas besoin d'un gros budget pour utiliser mysql, Linux, php, javascript, JQuery ou Xcode avec sqlite ou similaire selon l'environnement. Tout ça c'est gratuit et demande juste d'avoir les bonnes compétences.

avatar sinbad21 | 

Chez nous ce serait plutôt l’inverse. Utiliser de préférence un soft qui bégaie et qui duplique les cas.

avatar sinbad21 | 

Je n'aimerais pas, si j'étais astronaute, avoir du logiciel Microsoft à bord de la capsule ou de l'ISS.

avatar marc_os | 

@ sinbad21
Détrompe toi.
Microsoft est capable de faire de très bons logiciels pour professionnels.
Voir par exemple SQL Server.

Pages

CONNEXION UTILISATEUR