Un bogue dans un code Python pourrait avoir causé des erreurs de calcul dans des études scientifiques

**Bill Fassinou** · 14/10/2019, 15h26

Un bogue dans un code Python pourrait avoir causé des erreurs de calcul dans plus d'une centaine d'études scientifiques publiées
depuis 2014

Les programmes informatiques sont devenus comme des pivots dans plusieurs domaines de la vie, et l’on peut parfois être amené à surestimer l’exactitude des résultats d’un programme. Cependant, il peut arriver que certains programmes comportent des bogues qui pourraient engendrer de faux résultats. Récemment, des scientifiques hawaïens ont découvert un bogue dans un morceau de code Python qui aurait pu donner des résultats incorrects dans plus de 100 études publiées qui ont cité l'article original. Le bogue entraîne une variation des résultats d’un calcul en fonction du système d'exploitation utilisé.

Les scientifiques d’Hawaii ont détecté un bogue dans un morceau de code Python qui aurait pu donner des résultats incorrects dans plus de 100 études publiées qui ont cité l'article original. Le bogue a fait varier les résultats d'un calcul chimique, commun à plusieurs études, en fonction du système d'exploitation utilisé, ce qui a entraîné des divergences entre les systèmes Mac, Windows et Linux. Mardi, les chercheurs ont publié leur découverte et une version déboguée du script (d'environ 1 000 lignes de code) dans la revue Organic Letters.

À l’origine de la découverte, Yuheng Luo, un étudiant diplômé de l'Université d’Hawaii à Mānoa. Il s’est rendu compte du problème cet été alors qu'il vérifiait les résultats des recherches menées par le professeur de chimie Philip Williams sur les cyanobactéries (un embranchement de bactéries, également appelées « algues bleues »), en utilisant un script écrit en Python qui a été publié dans le cadre d'un article de 2014 dans la revue Nature Protocols. Les procédés du chimiste Williams consistaient à trouver des composés qui sont efficaces contre le cancer.

Le script utilisé par Luo calcule les valeurs de décalage chimique pour la RMN, ou spectroscopie par résonance magnétique nucléaire, une technique couramment utilisée par les chimistes pour déterminer la composition moléculaire d'un échantillon. Seulement, ses résultats ne correspondaient pas aux valeurs de RMN que le groupe de Williams avait précédemment calculées, et lorsque d’autres élèves ont à leur tour exécuté le code sur leurs ordinateurs, ils ont réalisé que les différents systèmes d'exploitation produisaient des résultats différents.

Nom : ol9b03216_0003.gif
Affichages : 153551
Taille : 28,9 Ko

Rui Sun, professeur de chimie à l'université d'Hawaii à Mānoa et qui supervisait les calculs de Luo, a ensuite ajusté le script pour corriger le problème, qui avait rapport à la façon dont les différents systèmes d'exploitation trient les fichiers. Patrick Willoughby, le premier auteur de l'étude de 2014, et qui a écrit le script, a qualifié la nouvelle étude de « bel exemple de science qui travaille pour faire avancer le travail que nous avons présenté en 2014 ». « Ils ont rendu un service extraordinaire à la communauté en révélant ce problème », a-t-il déclaré.

Le script comportant le bogue fait partir des scripts Python baptisés « Willoughby-Hoye », permettant de calculer les valeurs de décalage chimique pour la RMN (résonance magnétique nucléaire). Ce qui inquiète le plus les chercheurs, c’est que la découverte de ce bogue dans le script remet en question les conclusions de plusieurs autres études qui ont cité ou ont utilisé les résultats des calculs chimiques effectués par Patrick Willoughby en 2014. Ils estiment que les auteurs de ces études devraient reprendre leurs calculs avec le script corrigé.

« Ce simple bogue dans le script original remet en question les conclusions de plusieurs articles sur un large éventail de sujets d'une manière qui ne peut pas être facilement résolue à partir d'informations publiées parce que le système d'exploitation est rarement mentionné », ont-ils écrit dans leur article publié mardi dernier dans la revue Organic Letters. « Les auteurs qui ont utilisé ces scripts devraient certainement revérifier leurs résultats et toute conclusion pertinente en utilisant les nouveaux scripts modifiés », ont-ils ajouté.

Les chercheurs estiment que le bogue a pu produire de graves effets en aval. Par exemple, si le code amenait Williams à mal identifier le contenu de son échantillon, les chimistes essayant de recréer la molécule à tester en tant que médicament potentiel contre le cancer seraient à la poursuite du mauvais composé. Le nombre d’articles qui ont pu être affectés par ce problème n’est pas connu, car les chercheurs ne divulguent généralement pas le système d'exploitation qu'ils utilisent pour leurs analyses, il ne devrait pas être pertinent.

Néanmoins, d'après les données de Nature Protocols, le document de 2014 a été consulté près de 1900 fois et cité dans 158 autres études. Toutefois, il est également possible que toutes les études qui ont cité l'article n'aient peut-être pas utilisé le script qui contenait le bogue. Rob Keyzers, professeur de chimie à l'université Victoria de Wellington en Nouvelle-Zélande, qui avait cité le protocole dans une étude publiée cette année, a déclaré qu'il n'était pas au courant du problème et qu’il ne pense pas que cela affecte ses résultats.

Rob Keyzers a déclaré qu'il n'était pas « indûment inquiet » de ses résultats puisque son groupe n'a pas utilisé le script contenant le bogue. Malgré cela, il pense bien vérifier ses différentes conclusions. « Je vais certainement vérifier soigneusement nos données pour m'assurer que nous ne faisons pas de réclamations injustifiées », a-t-il ajouté. Williams et Sun ont contacté les auteurs de l'article original, les avertissant du bogue. Williams espère qu’ils travailleront ensemble pour informer les chercheurs qui avaient utilisé le code de l'existence du bogue.

Willoughby et Thomas Hoye prévoient de mettre à jour leur étude publiée dans la revue Nature Protocols. Ils ont reconnu le problème et fourniront le correctif écrit par le professeur Sun. Un porte-parole de Nature Protocols a également déclaré qu'ils examinaient les questions soulevées dans la nouvelle étude (publiée mardi par Sun et ses collaborateurs dans la revue Organic Letters), mais que pour des raisons de confidentialité, ils ne pouvaient commenter les cas individuels.

Selon Williams, l'incident rappelle que la science est collaborative et qu'elle s'autocorrige idéalement, mais que rien ne peut être tenu pour acquis. « C'est une erreur minime et subtile. Nous pensons tous en quelque sorte qu'un programme informatique génère toujours la bonne réponse », a-t-il conclu.

Source : ACS Publications, Étude originale (2014)

Et vous ?

Qu'en pensez-vous ?

Voir aussi

Microsoft arrête le déploiement de Windows 10 October 2018 à cause d'un bogue qui provoque la suppression des fichiers des utilisateurs

macOS : les langages de script tels que Python, Perl et Ruby ne seront plus préinstallés à partir de macOS Catalina pour plus de sécurité, dit Apple

Bash 5.0 est maintenant disponible. La cinquième version majeure du shell du projet GNU apporte de nouvelles fonctionnalités et corrections de bogues

**Daïmanu** · 14/10/2019, 15h58

Le titre alarmiste de cet article indique que le souci vient de Python, mais le texte parle du script Willoughby-Hoye.
Difficile de trouver des infos là dessus.

Ni cet article, ni les sources n'indiquent la nature exacte du problème.
Souci de représentation des nombres flottants ? Problème de consommation mémoire ?

Un exemple de script problématique aurait bien illustré l'article, surtout sur Developpez.

Et quelles sont les différences entre les différents OS ?

J'avoue rester sur ma faim sur ce coup là.

Edit: J'avais mal lu la news, le souci est bien mentionné

**Steinvikel** · 14/10/2019, 16h44

Il est également possible que le problème ne vient ni d'une erreur de script, ni d'un bug de Python, mais découlant simplement d'une fonction au "comportement non défini", si cher à nos analystes de sécurité.
...vous souhaitez du code fiable ? --> listez tous les éléments du langage employé ayant un comportement "non défini", et gardez-vous de les utiliser.

**wiztricks** · 14/10/2019, 16h53

Envoyé par Daïmanu

Ni cet article, ni les sources n'indiquent la nature exacte du problème. Souci de représentation des nombres flottants ? Problème de consommation mémoire ?

D'après la rumeur, ce code faisait pour hypothèse que différents OS trient les fichiers de la même façon (même la documentation d'os.listdir prévient là dessus).
Ce qui en soit n'a rien à voir avec le langage.

Pour le reste, c'est pas parce qu'on code avec Python qu'un programme qui produits des résultats dans un environnement système produira les mêmes dans un autre: il faut qu'un plan de tests s'attache à vérifier les dépendances, que les tests détectent les inconsistances (et qu'on oublient pas de les faire tourner).
Néanmoins, c'est bien que la communauté scientifique s'alarme un peu de la difficulté qu'il y a à programmer correctement et prennent des précautions lorsqu'ils s'échangent des codes.

- W

**fab256** · 14/10/2019, 17h26

Si un syseme X trie les fichiers differament d'un systeme Y, et que l'ordre des fichiers est important et peut changer le resultat final, c'est clair que ne n'est pas la faute au language. Souvant la partie fichier E/S è la partie qui doit etre adapté pour chaque systeme d'exploitation.

**frfancha** · 14/10/2019, 17h43

Il est écrit dans le post que le bug est une différence de tri de fichier entre OS.

Bon on est bien d'accord, quand une analyse scientifique dépend de la façon dont l'OS trie les fichiers le problème il est entre la chaise et le clavier.

**Bill Fassinou** · 14/10/2019, 19h48

Envoyé par Daïmanu

Un exemple de script problématique aurait bien illustré l'article, surtout sur Developpez.

Bien sur on mentionne les codes sources dans les actualités en général, quand on les as, souvent par exemple des sources sur github, ou collé dans la news directement avec la balise code, mais dans ce cas précis je n'ai pas trouvé le code Python dans les articles sources. Si quelqu'un le trouve, il est bienvenu pour le poster à la suite

**wiztricks** · 14/10/2019, 20h17

Envoyé par Bill Fassinou

je n'ai pas trouvé le code dans les sources. Si quelqu'un le trouve, il est bienvenu de le poster à la suite

çà devrait être(*):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
    def read_gaussian_outputfiles():
            list_of_files = []
            for file in glob.glob('*.out'):
                    list_of_files.append(file)
            list_of_files.sort()   # la correction.
            return list_of_files

Première ligne de la documentation de glob.glob:

The glob module finds all the pathnames matching a specified pattern according to the rules used by the Unix shell, although results are returned in arbitrary order.

(*) trouvé par ailleurs car il faut des droits d'accès pour les sources.

- W

**_informix_** · 15/10/2019, 09h21

Ce genre de bogue explique les disparités des études, les unes prônant le bien fait du café et les autres qui "prouvent" ça nocivité.

**Xanareld** · 15/10/2019, 10h48

J'ai bien lu l'article et les commentaires de chacun, mais je me demande si reporter la faute tantôt sur le langage, tantôt sur le système d'exploitation est bien raisonnable. Si j'ai une liste de fichiers à traiter dans un ordre précis, je vais définir cet ordre dans mon code au pire, dans un fichier annexe au mieux, et ne pas m'appuyer sur le tri que pourrait faire le système d'exploitation ou tout autre système de stockage (imaginons les fichiers sur un cloud, etc.)

J'imagine que ça offre une certaine souplesse d'ajouter/retirer des fichiers assez facilement que de s'en remettre au tri par le système d'exploitation mais ça me semble être là l'erreur première, d'avoir fait reposer sur le système d'exploitation un prérequis important pour le traitement des données, à savoir l'ordre de traitement des fichiers.

**Steinvikel** · 15/10/2019, 12h26

Personnellement, ce qui ressort de ma lecture, n'est ni la faute du langage, ni celle de l'OS, mais celle du savoir que détient le codeur.
Je suppose que ces scientifiques pissent pas mal de code, mais je doute qu'ils aient une maîtrise du langage aussi étendue qu'un développeur (qui varient déjà considérablement suivant le secteur). C'est typiquement ce genre de défauts que l'on retrouve constamment dans le projet d'un étudiant fraîchement sorti de l'école, mais qui apparaît moins souvent par un auteur "expérimenté".

me semble être là l'erreur première, d'avoir fait reposer sur le système d'exploitation un prérequis important pour le traitement des données

Je n'aurais pas mieux résumé. : )

**Jamatronic** · 15/10/2019, 13h46

Effectivement, le problème dans l'affaire est la médiocrité du / des programmeur(s).

Et ce n'est pas de la faute de Python s'il est le langage préféré des nuls en prog.

**Pierre Louis Chevalier** · 15/10/2019, 16h45

Envoyé par Xanareld

J'ai bien lu l'article et les commentaires de chacun, mais je me demande si reporter la faute tantôt sur le langage, tantôt sur le système d'exploitation est bien raisonnable

C'est pas le sujet, le sujet c'est que ce code n'est pas assez bon, qu'il est bugué, et qu'il a été utilisé sans vérifications. Donc après "les études sont faussées car elle sont financées par des intérêts privées" on a maintenant : "les études sont faussées car elle sont faites avec n'importe quel code pourri trouvé à gauche ou à droite".

**Steinvikel** · 16/10/2019, 02h45

Est-ce que les scripts, codes, et algo' dans le domaine de la recherche sont supervisés /vérifiés /approuvés par des codeurs professionnels ?
Parce qu'aux vues de la tendance générale des profils de moutons à 5 pattes dans le secteur IT, je vois très bien le même problème dans le secteur de la recherche ...où en plus, la formation de "programmation pratique" du cursus des moutons à 5 pattes (qui amène plus à être productif, que spécialisé), laisse penser au recruteur et sa hiérarchie, que ce mouton est compétant pour ce critère précis.

Quelqu'un du domaine aurait un avis à donner ? je ne fais que spéculer sur un cas que je ne connais que trop mal.

**Bardotj** · 16/10/2019, 10h44

soyons clair c est arrivé et cela arrivera encore.
developpeur ce sont des formations compléte bac+5 avec des méthodologies complètes et maintenant industrielles.

Il faudrait soit plus de formation sur le dev aux autres sections soit des équipes de dev et d’autres disciplines avec de la ci et des fermes de build. il est évident que les tests auraient detectés ce bug.

**Steinvikel** · 16/10/2019, 12h16

Dire que développeur = bac+5 automatique, c'est être un peu sévère non ?
C'est nier l’existence assez courante de profil BTS, voir licence, ou autodidacte + e-learning.

**Jiji66** · 16/10/2019, 18h20

Envoyé par Steinvikel

Est-ce que les scripts, codes, et algo' dans le domaine de la recherche sont supervisés /vérifiés /approuvés par des codeurs professionnels ?
.....

Ayant durant 15 ans jouer le rôle d'interface entre sciences (modèles mathématiques) et applications (implémentation informatique), je suis sur que les "algo" ne sont pas vérifiés par des codeurs professionnels. Ce qui se fait en généralement ce sont des tests qui vérifient des domaines de validités. Pour être plus clair, je suis persuadé qu'il y a une énorme quantité de bugs dans les "codes" scientifiques tout simplement parce qu’il est humainement difficile d’être individuellement bon dans tous les domaines et que l'informatique ne permet pas une transcription parfaitement juste de solutions analytiques.

**cervo** · 18/10/2019, 07h44

Effectivement, le problème dans l'affaire est la médiocrité du / des programmeur(s).

Et ce n'est pas de la faute de Python s'il est le langage préféré des nuls en prog.

Je dirais que l'intervention n'a plus rien avoir avec le sujet... c'est plutôt une attaque visée. ...