Une petite erreur d’Excel

Cet article est issu de la newsletter IA Comprise et reproduit ici par commodité. Recevez toutes les lettres dans votre boîte mail au fur et à mesure de leur publication en laissant votre adresse dans le cadre à droite !


Chère lectrice, cher lecteur,

Peut-être suivez-vous comme moi avec curiosité l’évolution du nombre de cas quotidiens de COVID-19.

Si vous avez consulté hier le nombre de cas au Royaume-Uni, vous avez pu apercevoir cela :

Nombre de cas quotidiens de COVID-19 au Royaume-Uni au 5 octobre (Our World In Data [1])

Quelle explosion !

L’épidémie est devenue incontrôlable, les hôpitaux vont bientôt être submergés, le Royaume-Uni est au bord du gouffre ?

À moins que… ce ne soit une erreur ?

Il y avait de quoi le soupçonner face à une hausse qui ne peut même plus être qualifiée d’exponentielle : le nombre de cas ne peut pas tripler du jour au lendemain.

C’est bien ce qui s’est passé ici : une grossière erreur, liée à l’utilisation Microsoft Excel, le tableur utilisé dans toutes les entreprises du monde.

Pour comprendre ce qui s’est passé, quelques éléments de contexte.

Comment compter les cas ?

Compter le nombre de personnes testées positives au COVID-19 paraît simple en théorie : les sites de tests collectent les résultats et les envoient à une autorité centralisée, qui les publie.

Mais c’est négliger un problème très terre-à-terre : les délais de test et de transmission.

Même si la date à laquelle un test a été effectué est bien enregistrée et transmise, entre le moment où une personne passe un test et celui où le résultat est comptabilisé dans les décomptes publics, il s’écoule plusieurs jours :

  • Le délai entre l’administration du test et les résultats
  • Le délai entre la collecte locale des résultats et l’envoi des résultats à l’autorité centralisée
  • Le délai entre la réception de ces résultats, leur vérification, leur agrégation et leur publication

Pour ne rien simplifier, ces délais varient eux-mêmes dans le temps et selon les lieux de collecte !

Il y a alors plusieurs possibilités pour compter les cas :

1. Attendre que tous les résultats soient arrivés pour les publier

Cela revient alors à s’aligner sur la source la plus lente : de précieux jours, voire semaines sont alors perdus dans l’évaluation de la situation sanitaire. Cette solution ne convient que pour une étude a posteriori d’une épidémie, pas en plein milieu où la réactivité est essentielle.

En attendant tous les résultats, on perd des informations précieuses sur l’évolution des derniers jours

2. Publier au fur et à mesure les résultats selon la date d’administration des tests

Cette solution est la plus rigoureuse : le nombre de cas au jour J correspond à tous les tests administrés ce jour J ayant donné un résultat positif, quelle que soit la date à laquelle ces résultats sont arrivés à l’autorité centrale.

Cette approche présente toutefois un défaut majeur : chaque mise à jour du graphe modifie non seulement les données du dernier jour affiché, mais également rétroactivement celles des jours précédents.

Il devient alors difficile de réellement suivre l’évolution au cours du temps et l’allure de la courbe sur les derniers jours devient trompeuse : plus une date est récente, plus il manquera de tests positifs (qui arriveront dans les jours suivants).

Cela donnera une fausse impression de baisse du nombre de cas sur les derniers jours.

En affichant les cas à la date du test, on modifie rétroactivement la courbe tous les jours et on « manque » d’autant plus de cas qu’ils sont récents

3. Publier au fur et à mesure le nombre de nouveaux cas reportés

Il reste donc une dernière possibilité [2] qui consiste à afficher chaque jour le nombre de nouveaux cas qui ont été communiqués dans les dernières 24h, peu importe la date réelle à laquelle le test a été administré.

En apparence ce n’est pas très correct : on mélange un jour donné des tests qui ont été administrés à plusieurs jours d’intervalle.

De plus, la courbe présente de grandes irrégularités, notamment les week-ends (où la communication des résultats n’a parfois pas lieu) et le lundi (où les cas du week-end sont rattrapés).

Afficher les cas reportés chaque jour donne une courbe en apparence très irrégulière, mais qui n’est pas modifiée rétroactivement

C’est pourtant cette approche qui est quasi exclusivement privilégiée dans tous les rapports, car elle permet de conserver intacte la courbe antérieure, en ne rajoutant chaque jour qu’un point.

Elle représente plutôt correctement les tendances récentes, car les variations de délai entre les différents sites se compensent en pratique assez bien.

Quant aux « bonds » liés aux week-ends, ils ne sont finalement pas si problématiques à partir du moment où on en est conscient, surtout si on lisse la courbe sur 7 jours.

Ce choix de représentation est cependant très sensible aux erreurs : vu que l’on ne modifie pas rétroactivement la courbe, une erreur est corrigée intégralement le jour où elle est découverte… et c’est ce qui s’est passé ici.

Une erreur de limite

Dans sa dernière version, Excel ne peut afficher qu’un peu plus d’un million de lignes – un progrès par rapport à quelques années plus tôt où la limite était de 65 000 lignes.

C’est largement suffisant pour beaucoup d’usages, mais cette limite peut être rapidement atteinte.

D’après le Guardian [3], le fichier utilisé pour manipuler les données quotidiennes avait dépassé cette limite il y a plusieurs jours : tous les cas qui étaient inscrits au-delà de la limite étaient simplement tronqués.

Lorsque l’erreur a été détectée le 5 octobre, les cas oubliés ont donc dû être rajoutés ce jour-là, en cohérence avec la méthodologie de représentation décrite plus haut.

Les 22 000 cas affichés le 5 octobre contiennent donc en réalité près de 16 000 cas rattrapés qui, si la transmission des résultats avait été correctement effectuée, auraient été répartis sur les jours précédents.

Finalement, la conséquence de cette erreur est qu’elle aura laissé croire pendant plusieurs jours que l’épidémie stagnait, alors qu’elle était en réalité en progression.

La faute à Excel ?

Le logiciel Excel a rapidement été désigné coupable de cette erreur fort gênante.

Ce n’est pas la première fois qu’il aura été à l’origine de « bugs » particulièrement graves ; par exemple :

  • En 2003, l’énergéticien canadien TransAlta a perdu 24 millions de dollars à cause de colonnes mal alignées [4]
  • En 2012, la banque JPMorgan a annoncé avoir perdu 6 milliards de dollars (!) entre autres à cause d’erreurs de copier/coller dans un modèle Excel [5]
  • En 2013, des étudiants pointent une coquille dans la feuille Excel utilisée par deux économistes dans un article phare de 2010 liant le niveau de dette à la croissance, article invoqué dans de nombreuses décisions macroéconomiques dans le contexte post-crise de 2008 [6]

Et je ne suis pas en reste, il m’est moi-même arrivé de faire des erreurs parfois gênantes avec Excel…

Haro sur Excel ? Ce n’est pas si simple.

La « faute » principale d’Excel est d’abord d’être très populaire et facile d’accès.

Cela peut donner une fausse impression de facilité et de rapidité, en négligeant ou minimisant la minutie nécessaire lorsque l’on travaille avec cet outil.

Si Excel est… excellent pour effectuer des séries de calculs, visualiser rapidement des données et construire des modèles simples, ce n’est pas un outil adapté dès lors que le modèle est complexe ou les données importantes, particulièrement si l’enjeu est important.

Dans ces situations, Excel peut remplir un rôle de prototypage, mais il est indispensable d’acquérir des notions de SQL (le langage des requêtes sur bases de données) voire d’un langage de programmation performant dans le traitement de données (Python ou R).

C’est certes intimidant à première vue (par où commencer ?), mais je suis persuadé que ce sont des compétences qui seront de plus en plus nécessaires, y compris hors des départements d’informatique.

Après tout, qui aurait cru il y a 30 ans que tant de personnes utiliseraient aujourd’hui au quotidien ce logiciel de calcul pour comptables nommé… Excel ?

À la prochaine,

Erwan


Inscrivez-vous gratuitement pour ne rater aucune lettre !


[1] https://ourworldindata.org/coronavirus/country/united-kingdom?country=~GBR
[2] Sans compter bien sûr toutes les approches intermédiaires
[3] https://www.theguardian.com/politics/2020/oct/05/how-excel-may-have-caused-loss-of-16000-covid-tests-in-england
[4] https://www.theglobeandmail.com/report-on-business/human-error-costs-transalta-24-million-on-contract-bids/article18285651/
[5] https://www.businessinsider.com/excel-partly-to-blame-for-trading-loss-2013-2
[6] https://www.businessinsider.com/reinhart-and-rogoff-admit-excel-blunder-2013-4

Laisser un commentaire

Abonnez-moi à la newsletter