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 354PARTAGES 30 2 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.





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 : É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 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.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 Qu'en pensez-vous ? Une erreur dans cette actualité ? Signalez-le nous ! Votre nom : Votre e-mail : Décrivez l'erreur que vous souhaitez porter à notre connaissance : 27 commentaires Poster une réponse Signaler un problème Les mieux notés Les plus récents Ordre chronologique Expert éminent sénior https://www.developpez.com Envoyé par Daïmanu Envoyé par 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 ?

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 12 0 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 Membre chevronné https://www.developpez.com

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é 10 0 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 surEt 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é Membre éprouvé https://www.developpez.com



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. 5 0 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. Expert éminent sénior https://www.developpez.com Envoyé par Bill Fassinou Envoyé par je n'ai pas trouvé le code dans les sources. Si quelqu'un le trouve, il est bienvenu de le poster à la suite

Code : Sélectionner tout 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

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. 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.



- W 5 0 çà devrait être(*):Première ligne de la documentation de glob.glob (*) trouvé par ailleurs car il faut des droits d'accès pour les sources.- W Expert éminent sénior https://www.developpez.com Envoyé par Xanareld Envoyé par 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 4 0 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". Expert éminent sénior https://www.developpez.com



C'est pas comme si un bug célèbre ne venait pas de temps en temps défrayer la chronique que ce soit dans le firmware des CPU, dans les OS: Windows, Linux, OSX, bibliothèques SSL,... tous y passent.



Les bugs font partie des risques de cette industrie.



Et lorsqu'on trouve un, on en parle histoire que ceux qui pourraient être impacté soient alertés et installent les corrections.

C'est juste ce qu'il se passe ici.



Après on peut toujours trouver "dommage" que seul quelques professionnels aient la rigueur nécessaire pour coder et puissent profiter des avancées de l'industrie du logiciel pour utiliser de la POO, écrire des suites de tests, des installations qui les tournent en continu pour s'assurer des non-régressions.



Est ce que toutes ces précautions nous affranchissent de découvrir un bug en production? Même pas. Il y en a toujours qui passent à travers.



Il ne faut pas oublier que si l'informatique à un intérêt, c'est pour ce qu'on en fait: les applications qu'elle permet de réaliser.



Et des applications, c'est d'abord des besoins utilisateurs qui vont souvent se débrouiller pour répondre à leurs besoins avec un code certes pourri mais qui le fait à peu près (regardez l'histoire de PHP).



Pas toutes auront la chance d'être vues comme des killers apps potentielles qui mériteraient d'être "industrialisées". Quand çà arrive, on fait appel a des professionnels pour les remettre d'équerre.



Comment croyez vous qu'ont démarré des monstres comme Exchange ou SAP?



Heureusement que c'est comme çà, car sans toutes des nouvelles applications (combien imaginées par les informaticiens?), beaucoup d'entre nous n'auraient pas de boulot.



Envoyé par jpiotrowski Envoyé par Et les études du GIEC, c'est en python ???

Comme on a besoin de performances, on va utiliser des bibliothèques écrites en Fortran ou en C depuis des dizaines d'années (les lois de la physique changent moins vite que les modes informatique). Au dessus, il y a peut être une couche de Python histoire d'avoir une interface un peu plus facile (c'est à çà que sert un langage de script). Python n'est pas ici un sujet.



- W 4 0 Vous devenez un peu lourds.C'est pas comme si un bug célèbre ne venait pas de temps en temps défrayer la chronique que ce soit dans le firmware des CPU, dans les OS: Windows, Linux, OSX, bibliothèques SSL,... tous y passent.Les bugs font partie des risques de cette industrie.Et lorsqu'on trouve un, on en parle histoire que ceux qui pourraient être impacté soient alertés et installent les corrections.C'est juste ce qu'il se passe ici.Après on peut toujours trouver "dommage" que seul quelques professionnels aient la rigueur nécessaire pour coder et puissent profiter des avancées de l'industrie du logiciel pour utiliser de la POO, écrire des suites de tests, des installations qui les tournent en continu pour s'assurer des non-régressions.Est ce que toutes ces précautions nous affranchissent de découvrir un bug en production? Même pas. Il y en a toujours qui passent à travers.Il ne faut pas oublier que si l'informatique à un intérêt, c'est pour ce qu'on en fait: les applications qu'elle permet de réaliser.Et des applications, c'est d'abord des besoins utilisateurs qui vont souvent se débrouiller pour répondre à leurs besoins avec un code certes pourri mais qui le fait à peu près (regardez l'histoire de PHP).Pas toutes auront la chance d'être vues comme des killers apps potentielles qui mériteraient d'être "industrialisées". Quand çà arrive, on fait appel a des professionnels pour les remettre d'équerre.Comment croyez vous qu'ont démarré des monstres comme Exchange ou SAP?Heureusement que c'est comme çà, car sans toutes des nouvelles applications (combien imaginées par les informaticiens?), beaucoup d'entre nous n'auraient pas de boulot.Le GIEC compile les résultats sortis de plusieurs modèles d'évolutions du climat qui tournent sur des super calculateurs.Comme on a besoin de performances, on va utiliser des bibliothèques écrites en Fortran ou en C depuis des dizaines d'années (les lois de la physique changent moins vite que les modes informatique). Au dessus, il y a peut être une couche de Python histoire d'avoir une interface un peu plus facile (c'est à çà que sert un langage de script). Python n'est pas ici un sujet.- W Chroniqueur Actualités https://www.developpez.com Envoyé par Daïmanu Envoyé par Un exemple de script problématique aurait bien illustré l'article, surtout sur Developpez. 3 0 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 Membre émérite https://www.developpez.com

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 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 3 0 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é".Je n'aurais pas mieux résumé. : ) Expert éminent sénior https://www.developpez.com



Envoyé par SQLpro Envoyé par 1) le libre est bien souvent moins contrôlé que les produits d'éditeur[





Avant d'utiliser en production un logiciel libre, on prend quelques précautions comme de savoir ce qu'en font ses utilisateurs. On peut aussi regarder dans la buglist les problèmes soumis et les réponses apportées. Et comme on a les sources regarder un peu les cas d'utilisation qui ont été testé.

Après ben on teste (même pour les logiciels produits par les éditeurs) que çà produit les résultats attendu dans les cas d'utilisation qu'on souhaite.



Et s'il y a plein de bugs et que la communauté des utilisateurs râle ben on utilisera autre chose.



Libre = gratuit mais il y a un autre travail à faire



Envoyé par SQLpro Envoyé par Et l'engagement de responsabilité implique des dommages et intérêts conséquents en cas de vice caché, et ici c'est bien d'un vice caché qu'il s'agit dans le cas de Python.





Quand un chercheur ajoute une étape de traitement qui permet de sortir la fréquence des molécules qu'il réalise pour valider une étude... Il doit publier son code pour que d'autres puisse reproduire ses résultats.

Après si d'autres chercheurs réutilisent ce code pour leurs traitements, on n'est pas dans la production logicielle mais dans les échanges normaux d'une communauté scientifique.



Envoyé par SQLpro Envoyé par Or dans le libre, il n'y a pas de contrat commercial, donc pas de responsable, donc pas d'indemnisation possible.





Envoyé par SQLpro Envoyé par 2) le développement est devenu au fil du temps de moins en moins fiable car les projets sont de plus en plus "urgent"....



Sûr qu'avant on avait des techniciens tant du côté entreprise que développeurs, aujourd'hui un commercial rencontre le directeur des achats et çà discute pépète.



Mais c'est pas un problème de logiciel libre/éditeur, c'est juste des organisations et des patrons qui ont oublié qu'ils n'y a pas que des objectifs financiers...



* * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *





- W 2 0 Salut,Avant d'utiliser en production un logiciel libre, on prend quelques précautions comme de savoir ce qu'en font ses utilisateurs. On peut aussi regarder dans la buglist les problèmes soumis et les réponses apportées. Et comme on a les sources regarder un peu les cas d'utilisation qui ont été testé.Après ben on teste (même pour les logiciels produits par les éditeurs) que çà produit les résultats attendu dans les cas d'utilisation qu'on souhaite.Et s'il y a plein de bugs et que la communauté des utilisateurs râle ben on utilisera autre chose.Libre = gratuit mais il y a un autre travail à faireLe problème est dans le code qui a été écrit avec Python et non dans Python.Quand un chercheur ajoute une étape de traitement qui permet de sortir la fréquence des molécules qu'il réalise pour valider une étude... Il doit publier son code pour que d'autres puisse reproduire ses résultats.Après si d'autres chercheurs réutilisent ce code pour leurs traitements, on n'est pas dans la production logicielle mais dans les échanges normaux d'une communauté scientifique.La plupart des logiciels libres qui ont pignon sur rue peuvent être utilisés librement ou avec un contrat commercial.Si le client veut de la daube pas cher, on lui livre de la daube pas cher et pleine de bugs. Et si les commerciaux des SSII se couchent devant le client pour faire du chiffre plutôt que d'assumer leur rôle de conseil et dire au client qu'il faut mettre un peu les moyens en fonction la criticité de l'application pour sa production....Sûr qu'avant on avait des techniciens tant du côté entreprise que développeurs, aujourd'hui un commercial rencontre le directeur des achats et çà discute pépète.Mais c'est pas un problème de logiciel libre/éditeur, c'est juste des organisations et des patrons qui ont oublié qu'ils n'y a pas que des objectifs financiers...Ah ces mecs du Sud, toujours dans lexagération- W Rédacteur https://www.developpez.com

À qui la faute ? 2 0 Tout cela me rappelle une anecdote où des résultats en chimie avaient été faussés parce que l'on utilisait des conteneurs en plastique au lieu de conteneurs en verre.À qui la faute ? Poster une réponse Signaler un problème

