gouttegd a écrit 1805 commentaires

Ce serait une solution en effet.

Mais à mon avis ce n’est guère utilisable que pour un document que l’on souhaite non-éditable (comme le seraient d’ailleurs les formats .webarchive, .mhtml etc., s‘ils étaient plus largement supportés), parce que du HTML comme format d’édition, ça ne me paraît pas terrible, c’est plus un format d’export.

En gros ça peut sans doute remplacer un PDF, mais pas un ODT ou un DOC(X).

Ça rend les documents difficile d'accès, parce qu'il faut d'abord ingérer la mise en page.

Je ne suis pas sûr de comprendre ce que tu veux dire, là… Qu’est-ce que tu entends par « ingérer la mise en page », et en quoi est-ce que ça rend les documents « difficile d’accès » ?

Ce que je crois comprendre est que l’auteur d’un document doit d’abord se farcir la définition de ses styles, alors que c’est quelque chose qu’il n’aurait pas à faire avec Markdown. DU coup c’est ça qui rendrait l’utilisation des logiciels de traitement de texte plus difficile.

Si c’est bien là ce que tu veux dire, plusieurs choses :

L’auteure n’est pas obligée de définir ses propres styles (elle peut se contenter des styles par défaut, auquel cas elle est dans la même situation que celle qui utilise Markdown ou assimilé). Mais si elle le fait, en général c’est bien parce qu’elle en a besoin. C’est justement un des avantages à utiliser un traitement de texte plutôt qu’un langage de balisage léger : on peut définir ses propres styles.

Un gros avantage de définir ses propres styles (et, du coup, un gros inconvénient des langages de balisage léger qui n’offrent pas cette possibilité) est la possibilité de dissocier la sémantique de la mise en forme. Un traitement de texte (ici je mettrais dans cette catégorie les langages de balisage non-légers comme LaTeX, puisque eux aussi permettent la dissociation sémantique/mise en forme, même si c’est par des moyens différents — macros plutôt que styles), je peux faire la différence entre quelque chose que je veux mettre en italique parce que c’est un nom d’espèce (p.ex. Homo sapiens), quelque chose que je veux mettre en italique parce que c’est un nom de gène (p.ex. grainyhead), quelque chose que je veux mettre en italique parce que c’est un mot d’origine étrangère pas encore passé dans le vocabulaire courant, quelque chose que je veux mettre en italique parce que je veux insister dessus, etc. Avec un langage de balisage léger à-la-Markdown, tous ces mots se retrouveraient en italique pour la même raison (parce qu’ils ont été écrits entre deux signes _).

Tiens, sur LinuxFR.org par exemple, il n’y a qu’un seul moyen de mettre un paragraphe en exergue, c’est d’abuser de la balise de citation, comme ci-dessous :

Ce paragraphe est en exergue. Ce n’est pas une citation. On ne sait pas bien pourquoi il est en exergue en fait. Il n’apparaît pas différemment du premier paragraphe de ce commentaire, qui lui est bien une citation du commentaire parent.

Un balisage sémantique (comme ce que permet un traitement de texte avec ses styles) permet par exemple de faire la différence entre un paragraphe mis en exergue parce que c’est une citation, et un paragraphe mis en exergue parce que c’est un avertissement aux lecteurs.

Les logiciels produisent des documents sous formes de pages pour l'impression qui ne sont pour la plupart jamais imprimées.

Je pense que des « documents sous formes de pages pour l’impression » sont toujours utiles aujourd’hui, quand bien même ces documents ne seraient que rarement imprimés.

Un fichier ODT, DOC(X), ou PDF, c’est bien pratique par exemple quand on veut faire circuler un document entre plusieurs personnes (par email par exemple). Le fichier contient tout le nécessaire (p.ex. images, tableaux), se suffit à lui-même, et ne nécessite aucune « plate-forme web » pour pouvoir être échangé.

La plateforme Web d'aujourd'hui permet la rédaction en colonne, l'insertion de média en médaillon, la rédaction collaborative, et l'affichage en fonction de la taille du support.

Encore faut-il avoir accès à une telle plate-forme.

Une page HTML, il faut l’héberger quelque part pour qu’elle soit consultable, et ce n’est pas toujours possible ou facile :

• on n’a pas forcément un serveur web à disposition ;
• variante : on travaille pour une organisation qui a certes un serveur web, mais publier un fichier dessus nécessite de faire une demande en trois exemplaires au service communication avec l’aval d’un sous-directeur quelconque — si elle est acceptée, la demande sera exécutée au bout de trois mois ;
• on peut ne pas vouloir que le document soit accessible aux quatre vents ; publier sur un serveur web réservé au réseau local est une possibilité, mais parfois on peut quand même vouloir souhaiter faire parvenir le document à une ou deux personnes bien précises à l’extérieur de l’organisation.

Dans le cas d’une page HTML simple, on peut certes envoyer la page par email de la même manière qu’on enverrait un ODT ou un PDF, mais ça ne marche plus dès lors que le document comporte des images. Un ODT ou un PDF est auto-suffisant (le fichier contient tout), une page HTML non.

Il manque, à ma connaissance, un format standard et largement supporté pour envoyer une page HTML et les ressources dont elle dépend dans un fichier unique auto-suffisant. Sous MacOS, Safari a son format .webarchive, mais je ne crois pas qu’il soit pris en charge ailleurs (en tout cas pas nativement). À une époque, Firefox avait son format .maff, Konqueror son .war, Internet Explorer son .mhtml… je ne connais aucun format d’archive web qui soit suffisamment répandu pour qu’on puisse se permettre d’envoyer une page dans ce format en étant raisonnablement certain que tout le monde pourra la visualiser sans avoir besoin d’installer un logiciel ou greffon ad-hoc.

Certes, pour faire circuler (et éventuellement collaborer sur) un document, il y a aussi les solutions de type Google Doc et assimilés, et ça peut dans certains cas être valables.

Mais personnellement je trouve que les capacités de mise en forme de Google Doc sont quand même très limitées par rapport à celle de Writer, de Word, ou de ce que je peux faire avec DocBook. Rien que l’impossibilité de définir ses propres styles est rédhibitoire pour moi.

À noter que même dans le cas où la modification est de taille suffisamment conséquente pour être aisément repérable (ici par exemple), il reste pénible de devoir scroller jusqu’en bas de la dépêche pour découvrir la modification.

(Du coup, proposition de contournement si n’afficher que le paragraphe modifié s’avère trop difficile : interdire les dépêche de plus de cinquante lignes, comme ça le diff tient sur un écran sans avoir besoin de scroller ! :P )

tu es daltonien ?

Pas à ma connaissance. :)

Personnellement, je trouve que les couleurs permettent de repérer les modifications rapidement.

Une modification comme celle-là, oui. :)

Une modification comme celle-ci, non. :( C’est le genre de modifications à me faire m’arracher les cheveux à la recherche des caractères rouges et verts (j’ai du faire défiler le texte entier dans un sens et dans l’autre au moins quatre ou cinq fois avant de repérer la modif).

Je fais remonter ce ticket pour préciser que dans mon expérience, le second problème mentionné (« en modifiant un caractère on a dans le différentiel tout le corps de la dépêche et non uniquement le paragraphe concerné ») est systématique. Ça ne concerne pas que certaines révisions. Chaque fois, c’est toute la dépêche qui est affichée dans le diff, ce qui peut rendre très pénible de trouver la modification si celle-ci ne concerne que quelques caractères ou mots noyés dans un texte de 50 000 caractères.

Ben justement, il est possible que Kangjie Lu (le directeur de thèse) ait été dupé par son étudiant…

On n’attend pas des directeurs et directrices de thèse qu’ils soient en permanence derrière leurs étudiants ou étudiantes. Au contraire, une certaine autonomie est attendue.

On peut imaginer que Kangjie Lu et Qiushi Wu ont conçu et planifié l’expérience ensemble, mais qu’ensuite Kangjie Lu a laissé son étudiant se charger de la réalisation. En constatant l’échec, Qiushi Wu aurait alors pu mentir à son directeur de thèse (« oui oui, réussite totale, prof : tous les patchs ont été acceptés, ils n’y ont vu que du feu ! »).

Si c’est ce qui s’est passé (je rappelle que c’est de la pure spéculation : on ne sait pas ce qui s’est passé exactement, à part qu’il y a eu fraude), alors on peut éventuellement reprocher à Kangjie Lu un défaut de supervision (débatable, parce qu’il ne me paraît pas forcément très raisonnable d’attendre d’un directeur ou directrice de thèse qu’il supervise son étudiant ou son étudiante de suffisamment près pour éviter toute fraude — où s’arrête la supervision et où commence la surveillance ?). Légalement il serait probablement toujours responsable (c’est son étudiant, sa responsabilité), mais au moins moralement la faute incomberait à Qiushi Wu.

Je peux aussi imaginer un scénario où la fraude serait le fait de Qiushi Wu, et où Kangjie Lu après s’en être rendu compte (possiblement « grâce » aux remous causés par l’Affaire) aurait décidé de régler le problème entre quatre z’yeux, genre « t’as de la chance, tout le monde s’est tellement focalisé sur cette histoire d’éthique que tes petits arrangements avec la réalité des conclusions de l’expérience sont passés inaperçus ; on a rétracté le papier donc il n’y a pas de raison que ça aille plus loin, ça restera entre nous — mais si tu me refais un coup pareil tu peux faire une croix sur ta thèse, capisce ? »

« Les pauvres gamins ? » Pardon ???

Kangjie Lu est un Assistant Professor (en gros et même si c’est difficilement comparable étant donné la différence entre les systèmes US et français, l’équivalent d’un « chargé de recherche 1er niveau » ou d’un « maître de conférence » fraîchement recruté en France), ce n’est ni un gamin ni un étudiant.

Certes il n’a pas de tenure et il est donc sous la pression du publish or perish, mais c’est le lot de quasiment toutes les personnes qui font de la recherche. Lui trouver des excuses est une insulte aux milliers de chercheurs et chercheuses qui, sous le coup de la même pression, s’efforcent pour autant de faire de la recherche de qualité en restant intègres.

Quant à Qiushi Wu, il est doctorant, il n’a certainement pas « 18-21 ans tout au plus ». Il a commencé son doctorat en 2018, donc il doit plutôt être à 24-25, minimum. C’est certes jeune, mais encore une fois, des milliers de doctorants et doctorantes du même âge font leur thèse sans se livrer au bidonnage.

La vraie question ici, c’est qui de Qiushi Wu ou de Kangjie Lu est à l’origine de la fraude. Des doctorants ou doctorantes qui bidonnent leurs résultats de leur propre chef, ça arrive, mais des directeurs ou directrices de thèse qui encouragent les personnes sous leur supervision à bidonner, ça arrive aussi… Dans quel cas de figure est-on ici, on n’en sait rien.

(Et on n’en saura probablement jamais rien : la fraude a été complètement passée sous silence, le papier a déjà été rétracté, donc il n’y ara probablement jamais d’enquête par l’Office of Research Integrity, donc on ne saura jamais ce qui s’est passé exactement.)

Je ne comprends pas l'intérêt de retirer le hachage en javascript qui était fait sur le mot de passe lors de l'authentification.

Sans HTTPS, le chiffrement (pas le hachage : si j’ai bien compris, ce qui se passait dans les versions précédentes était que le mot de passe était chiffré côté client par du code Javascript, puis envoyé au serveur où il était déchiffré puis haché, le hash étant alors stocké en base) côté client par Javascript n’apporte pas grand’chose, puisque le code Javascript réalisant le chiffrement est délivré au navigateur à travers une connexion non-sûre.

Supprimer l’étape de chiffrement par Javascript (donc envoyer directement le mot de passe tel quel au serveur, qui n’a plus qu’à le hacher et le stocker) pour se reposer exclusivement sur le chiffrement de la couche TLS est une bonne pratique.

Certes, de nos jours, il n'y a plus beaucoup de raisons de ne pas avoir de chiffrement sur les échanges, mais dans un réseau local c'est parfois un peu plus compliqué.

Si tu es sur un réseau local auquel tu fais suffisamment confiance pour ne pas utiliser TLS, mais que tu aimerais quand même que ton mot de passe soit chiffré, c’est que tu ne fais pas tant confiance que ça à ce réseau local et donc que tu devrais activer TLS. :)

J'ai fait ces corrections avant que tu ne soumettes la dépêche et c'était dans l'historique !

Oui, j’avais bien compris.

C'est même aussi en partie pour ça que j'interviens assez souvent dans les dépêches en rédaction. Pour que les auteurs et autrices puissent voir ce que je fais.

Sauf que je suis désolé (d’autant plus que tu n’es, je suppose, pas responsable de ça, c’est le site qui est mal fichu), mais en pratique sur une dépêche longue l’historique est impraticable pour revoir des petits changements.

Si le site était bien fichu, quand on demande l’affichage d’une révision il n’afficherait que le paragraphe qui a été modifié, avec éventuellement une ou deux lignes de contexte avant et après (comme un diff classique). Sauf que non : il affiche tout le texte de la dépêche, et surligne simplement en rouge ce qui a été changé. Charge au rédacteur ou à la rédactrice de parcourir tout le texte à la recherche des passages surlignés en rouge.

Excuse-moi de ne pas perdre mon temps à faire ça chaque fois que je vois que quelqu’un a édité la dépêche. Je le faisais au début, mais après avoir passé plusieurs minutes à chercher « mais il est où le passage édité bon sang ?! », tout ça pour découvrir au bout du compte que l’édition était simplement le remplacement d’une espace fine par une espace insécable à la ligne 1739, j’ai décidé que j’avais mieux à faire. Je pars désormais du principe que toutes les éditions sont mineures, faute pour l’éditeur ou l’éditrice de signaler explicitement le contraire.

Tu aurais laissé un simple message du genre « j’ai rajouté “et développeuses” par endroit, l’usage du masculin comme neutre n’est pas acceptable sur LinuxFr.org, merci de faire attention », j’aurais fait le nécessaire pour adapter la dépêche en conséquence et m’assurer qu’aucun masculin neutre ne subsiste. Crois-le ou non, je l’aurais fait avec plaisir, parce que fondamentalement ma position sur l’écriture inclusive pourrait se résumer à « à Rome, fais comme les Romains » : je n’utilise pas spontanément l’écriture inclusive mais je n’ai aucune objection à le faire si j’interviens sur un site où elle en vigueur ou semble être attendue. Encore faut-il que je sache que je sois à Rome, cf. ci-dessous.

Donc voilà.

Donc voilà. On a une dépêche incohérente, qui si je n’en étais pas le principal auteur me donnerait l’impression d’avoir été écrite par ce que j’appelle un féministe de pacotille, le genre à parler presque toujours au masculin mais à quand même balancer un féminin par-ci par-là comme pour bien dire « vous avez vu ? dans le neuvième paragraphe j’ai pensé à l’existence des femmes, j’suis un gars bien hein ? je peux avoir ma médaille d’Allié Féministe™ SVP ? ». Vraiment, je ne te remercie pas.

Mais par principe, les dépêches ne devraient pas être essentiellement au masculin, car le masculin n'est pas une forme du neutre.

Comme déjà signalé, je n’ai pas de problèmes avec cette position.

Mais est-ce la position d’Ysabeau ou la position de LinuxFR.org ?

Parce que si c’est la position de LinuxFR.org, la moindre des choses serait qu’elle soit exposée quelque part. Je n’en ai jamais vu nulle trace sur les pages d’aide du site. Partout il n’est jamais question que d’auteur, de modérateur, de mainteneur.

Alors certes, j’ai déjà vu plusieurs de tes messages où tu interviens comme modératrice et j’ai bien remarqué que, comme le dis tisaac, tu es sensible à cette question. Mais en l’absence de politique explicite (du moins visible !) à l’échelle du site et après des mois dans l’espace de rédaction sous aucune réaction (visible ! une addition en douce de deux mots dans une dépêche de cette taille n’est pas visible, désolé) ni de ta part ni de que qui ce soit d’autre, j’ai supposé que je n’étais pas à Rome et que personne n’attendait de moi que je me comporte en Romain.

Je veux bien en accepter une part de responsabilité (oui, j’aurais du étudier minutieusement chaque édition pour vérifier si, par hasard, l’une d’elles aurait pu me laisser comprendre que ah tiens, on est en territoire inclusif ici), mais LinuxFR.org a aussi la sienne.

En l’état, tout indique que LinuxFr.org n’a pas de politique cohérente sur la question, et que c’est au petit bonheur la chance en fonction de l’humeur du modérateur ou de la modératrice (selon que le modérateur vient de finir de lire un bouquin sur le féminisme par exemple…). Ça ne me semble pas tenable, désolé.

si un officier nazi (disons Adolfo Ramirez, « c'est français, police française ! ») me demande si j'héberge et cache un juif chez moi, puis-je lui mentir ? Kant répondrait par la négative : tu ne dois pas mentir… mais rien ne t'oblige à lui répondre. ;-)

Euh, je ne suis pas philosophe, mais j’aimerais quand même avancer l’idée que la présence d’un officier nazi vraisemblablement armé et pas forcément disposé à accepter une non-réponse n’est pas tout-à-fait « rien ». :)

Pas étonnant que je ne l’ai pas remarqué du coup, je suppose (en aparté : l’interface de l’espace de rédaction est juste horrible quand il s’agit de voir quels changements ont été faits).

Il n’empêche :

• Ou bien on considère que le masculin peut représenter le neutre, auquel cas « développeurs et développeuses » n’est jamais nécessaire parce que toujours redondant (en plus d’être trompeur, puisqu’il fait croire que l’auteur ne considère pas que le masculin puisse être neutre, ce qui influence l’interprétation de tous les autres usages du masculin dans le texte).
• Ou bien on considère que le masculin ne saurait avoir valeur de neutre, auquel cas « développeurs » n’est jamais acceptable pour désigner tous les développeurs.

Je n’ai rien contre la seconde position, mais il faut choisir entre l’une ou l’autre, je ne vois pas comment elles pourraient être compatibles. On ne peut pas dans un paragraphe parler de « développeurs » en voulant désigner tout le monde (le masculin est neutre, OK ?), dans le paragraphe suivant parler de « développeurs et développeuses » (le masculin désigne les hommes exclusivement, OK ? N’invibilisez pas les femmes !), puis dans le paragraphe d’après reparler seulement de « développeurs » (bon, là j’ai eu la flemme de répéter « et développeuses » et puis de toute façon c’était trop lourd, mais promis ça désigne bien tout le monde).

(À la limite, utiliser « développeurs et développeuses » lors de la première occurence pour bien signifier qu’on veut n’oublier personne, puis ensuite en rester au masculin neutre par souci de « légèreté ». Mais du coup ça ressemblerait plus à du virtue signalling qu’à un vrai souci d’être inclusif, à mon avis.)

’fin bref. Ce que j’aurais apprécié ici, si Ysabeau ou qui que ce soit d’autre avait un problème avec l’emploi exclusif du masculin dans la dépêche (« développeurs » mais aussi « étudiants », « organisateurs », « contributeurs », et probablement quelques autres), c’est qu’on me le dise pendant que la dépêche était encore en rédaction, parce que j’aurais été parfaitement disposé à opter pour une autre forme (par exemple, j’aurais volontiers proposé une forme au féminin neutre, avec l’accord des autres rédactrices).

Alors ici et là j'ai mis "développeurs et développeuses", mais pas partout pour ne pas alourdir.

Je n’avais pas fait attention, et franchement ça ne me plaît guère.

Pourquoi ?

Parce que tant que seule la forme masculine est présente, il est plausible qu’elle a été employée en tant que forme neutre.

On n’en sait rien, certes (personne n’est dans l’esprit du rédacteur pour le savoir), mais c’est plausible.

Par contre, dès l’instant où la forme combinée masculine et féminine est présente, même une seule fois, on ne peut plus raisonnablement prétendre que la forme masculine représente le neutre. Si l’auteur pensait que le masculin est neutre, il n’emploierait jamais la forme combinée masculin+féminin qui serait redondante, donc il faut en conclure que l’auteur pense que le masculin ne représente que… le masculin.

Autrement dit, partout où seule la forme « développeurs » apparaît seule, on ne peut plus que comprendre que j’ai voulu désigner les seuls développeurs hommmes.

Ce n’était pas mon intention, et je ne vous remercie pas.

Je n’ai rien contre l’écriture inclusive, sous quelque forme que ce soit, mais à condition d’être cohérent.

Je trouve ça un peu gonflé de reprocher ça à un commentateur alors qu’on ne l’a jamais reproché au principal auteur de la dépêche, qui tout au long de celle-ci n’a jamais parlé que de développeurs et de mainteneurs.

Il y a clairement des développeuses parmi les développeurs du noyau. J’ai utilisé le masculin comme neutre pour désigner aussi bien développeurs que développeuses, ce qui n’a semblé poser de problème à personne pendant les mois pendant lesquelles cette dépêche est restée dans l’espace de rédaction.

Pourquoi le masculin comme neutre serait acceptable dans le corps de la dépêche mais pas dans les commentaires ?

Je croyais que dans le cas où un traitement existe déjà et que le but est d'évaluer l'efficacité d'un nouveau traitement, on comparait dans les études non pas avec un placebo mais avec le traitement de référence pour ne pas faire perdre de chances aux participants qui n'auront pas le nouveau traitement. Je me trompe ?

Ça dépend du type d’essai, mais en principe quand on veut tester l’efficacité, oui, s’il existe un traitement de référence c’est ce qu’on donnera au groupe contrôle. Si on veut tester l’innocuité (essai de phase I), normalement on donnera un placebo.

Par contre placebo vs nouveau traitement […] je ne vois pas spécialement le problème éthique

La question ici n’est pas de savoir s’il est éthique de donner un placebo, mais s’il est éthique de ne pas donner une information complète au patient. Il est acquis en matière d’essais cliniques qu’idéalement les patients ne doivent pas savoir s’ils ont reçu un placebo ou la molécule à tester (les médecins non plus d’ailleurs, c’est pour ça qu’on parle de double-aveugle), je me demandais si c’était compatible avec la déontologie kantienne.

En y repensant je suppose qu’on peut s’en sortir en disant au patient « on vous donne un médicament OU un placebo ». C’est la stricte vérité, mais je demande où ça se place en terme de tromperie, duperie ou fourberie — ça reste de la rétention délibérée d’information, c’est éthiquement recevable m’sieur Kant ?

Que penserait Kant des essais cliniques en double-aveugle ? C’est pas éthiquement acceptable de donner un placebo aux patients du groupe contrôle en leur faisant croire qu’on leur donne une molécule active ? Il vaut mieux avoir des médicaments dont on n’est pas certain de l’efficacité au-delà de l’effet placebo ?

Si vraiment une action devait être tentée je pense que les développeurs noyau auraient un chouia plus de chance un avançant un préjudice moral (en gros ce que décrit Jehan dans son troisième point ici) plutôt que la perte de temps, même si je suis tout-à-fait d’accord que celle-ci est réelle.

Sur la perte de temps, on pourrait rétorquer que de toute façon étudier des patchs fait partie du travail des mainteneurs, et que le fait que les patchs aient été soumis de mauvaise foi n’y change rien — si les patchs avaient été soumis de bonne foi, les mainteneurs auraient passé autant de temps dessus. (Je ne dis pas que je suis d’accord avec ça, mais je pense que c’est une défense qui se tiendrait.)

Par contre, la déception, le sentiment de trahison, l’agression psychologique dont parle Jehan, ça c’est bien directement une conséquence du caractère hypocrite de ces patchs.

Précautions d’usage : I Am Not A Lwayer.

Je pense qu’il y a plusieurs questions à se poser pour tenter de répondre :

1) Qui aurait qualité à agir ?

Possiblement la Linux Foundation je suppose. Les développeurs du noyau à titre individuel, peut-être, encore que ça me semble moins probable.

J’ai de gros doutes sur le fait que les utilisateurs du noyau (qu’ils s’agissent d’utilisateurs individuels ou de sociétés qui d’une manière ou d’une autre utilisent le noyau dans le cadre de leurs affaires — par exemple, un hébergeur qui propose des serveurs sous Linux à ses clients) puissent être considérés comme des parties recevables. Mais ça dépend aussi de la question suivante.

2) Quelle législation s’applique ?

À première vue la loi américaine (la Linux Foundation est une association américaine, les deux chercheurs sont affiliés à une université américaine). Mais si la loi française considère que des utilisateurs de Linux auraient qualité à agir (aucune idée si c’est le cas ou pas), alors je suppose qu’une boîte française comme OVH par exemple pourrait peut-être porter l’affaire devant les tribunaux français.

Il me semble (/!\ IANAL IANAL IANAL /!) que la loi française (tout comme la loi américaine d’ailleurs) ne se soucie pas forcément de savoir si l’infraction a eu lieu sur le territoire national ou si les auteurs sont français — si une victime identifiée est française, c’est suffisant pour que la loi française soit applicable. (/!\ IANAL IANAL IANAL /!)

3) Quelle infraction peut-on reprocher, le cas échéant ?

Dans la loi américaine, aucune idée.

Dans la loi française, pas sûr. Ce n’est clairement pas, il me semble (IANAL alert !), du « piratage informatique » (« accès ou maintien frauduleux dans un système de traitement automatisé de données », article 323-1 du code pénal). Je ne pense pas non plus que ce soit de l’« introduction frauduleuse de données » (article 323-3). Ça pourrait relever de l’« entrave au fonctionnement d’un système de traitement automatisé de données » (article 323-2), je suppose.

Ça c’est pour le pénal. Au civil, je doute très fortement que la moindre action soit possible (j’ai déjà de gros doute pour une action pénale de toute façon), puisqu’il me semble que le demandeur devrait prouver que l’action des chercheurs lui a causé un dommage. Les patchs n’ayant en définitive pas été introduit dans une version publiée du noyau, je ne vois pas comment quiconque pourrait prétendre avoir subi un dommage. Les développeurs noyau pourraient à la limite prétendre à un préjudice moral, mais ça me paraît léger pour fonder une action en justice.

/!\ IANAL IANAL IANAL /!\

Mais, une fois les premières étapes de tâtonnement franchies par le vulgus pecum qui s'initiait aux délices d'un système inconnu mais plein de promesses, le même initié constatait avec joie que … "ça marche !"

Mandatory geekscotte :

Mais comment est-ce possible, même logistiquement? Un chercheur soumet plusieurs projets par an, chaque projet peut impliquer des collaborateurs d'organismes différents, qui n'ont pas les mêmes règles et les mêmes procédures. Il me semble totalement impossible de suivre individuellement les milliers de projets soumis dans toutes les disciplines

Bah déjà tu sembles penser que le moindre projet de recherche doit passer devant un comité d’éthique. Ce n’est absolument pas le cas. On entend sûrement beaucoup plus souvent parler des travaux de recherches qui posent des problèmes éthiques (ça fait forcément plus de « bruit », c’est normal et c’est d’ailleurs probablement une bonne chose), mais il y a beaucoup de travaux qui n’en posent pas du tout.

J’ai fait dix ans de recherches en biologie en France, aucun de mes projets n’est jamais passé devant un comité d’éthique. J’ai travaillé soit sur des cellules humaines en culture, dont personne ne pense qu’elles posent un problème éthique (c’aurait été différent s’il s’était agi de cellules primaires — en provenance directe de patients, par opposition à des cellules cultivées en laboratoire depuis des années —, parce que là il y aurait eu des considérations éthiques liées notamment au consentement des patients — « êtes-vous d’accord pour que votre biopsie soit utilisée à des fins de recherche ? » — et à la gestion des données personnelles des patients — double nécessité de maintenir une traçabilité des patients jusqu’aux cellules et de préserver l’anonymat des patients), soit sur des mouches, qui similairement ne posent aucun problème d’éthique (même pas des considérations liées à la souffrance animale, ce qui n’aurait pas été le cas avec des souris par exemple).

Bref, il y a un premier « filtre », représenté par les chercheurs eux-mêmes, à qui il appartient de se poser la question « est-ce que ce que je fais soulève des questions éthiques ? ». Assez souvent, la réponse est évidente, dans un sens ou dans l’autre. Évidemment, cela suppose que les chercheurs soient un minimum sensibilisés à l’éthique, ce qui devrait normalement faire partie de leur formation — j’ai le regret de dire que ça n’a pas franchement été le cas pendant ma formation universitaire en France.

Ensuite, c’est pas comme s’il n’y avait qu’un seul comité d’éthique dans toute l’université, chargé d’évaluer tous les projets. (Je rappelle que je décris ce qui se passe au Royaume-Uni — peut-être qu’en France les universités se dotent d’un comité d’éthique pour plusieurs milliers de chercheurs, j’en sais rien et je ne suis pas sûr que je serais étonné que ce soit le cas…) Il y a au minimum un comité par département (logique, on ne va pas demander au même comité d’évaluer à la fois des projets de biologie et des projets de sécurité informatique…), et un comité « supérieur » à l’échelle de l’université entière. Dans les plus gros départements, il peut aussi y avoir des comités « sous-départementaux », à l’échelle d’un (gros) institut par exemple.

Le principe est que si le chercheur estime que son projet soulève des questions éthiques (premier filtre), il le fait évaluer par son comité le plus « proche » (celui de l’institut s’il y en a un, sinon celui du département). La plupart du temps, le projet est suffisamment simple, et les questions éthiques soulevées suffisamment « standard » (les projets soulevant des questions éthiques complètement nouvelles ne sont pas si fréquents…), pour que le comité local se considère compétent pour approuver ou retoquer le projet, ce qu’il fera lors de sa prochaine réunion (une par mois en moyenne).

Parfois, le comité local estime que non, il n’est pas compétent et que le projet devrait être soumis à l’échelon supérieur.

Parfois encore, la nature même du projet fait que les chercheurs savent d’emblée que le comité local ne sera pas compétent. C’est typiquement le cas des projets de recherches biomédicales impliquant directement des patients (essais cliniques par exemple), parce que là la réglementation britannique en la matière impose que ces projets soient validés par les comités d’éthiques nationaux du NHS — les comités d’éthiques des universités, à quelque niveau que ce soit, ne sont explicitement pas compétents juridiquement pour ces projets.

Dans ce cas, le rôle des comités universitaires n’est plus d’évaluer le projet, mais d’aider le porteur du projet à monter son dossier auprès des comités nationaux. Parce qu’un dossier d’évaluation auprès des comités du NHS, c’est relativement pas de la tarte, voire même franchement pas évident pour quiconque n’a pas l’habitude. Et l’université n’a évidemment aucun intérêt à laisser ses chercheurs aller au « casse-pipe » devant un comité national avec un dossier mal ficelé, ce serait une perte de temps pour tout le monde (les chercheurs et les membres du comité national).

Pour les OGM confinés (qui ne sont pas disséminés dans la nature), l'agrément est donné au laboratoire pour une certaine période, on n'est pas du tout dans un cas d'analyse des expériences individuelles.

Non, et si.

Il y a bien un agrément donné au laboratoire (voire l’institut) entier, mais celui-ci ne couvre pas nécessairement tous les projets menés dans le laboratoire/institut et un chercheur peut avoir besoin d’un agrément invidivuel pour son propre projet (ça a été mon cas, à deux reprises). Et là du coup on est bien dans le cas où la commission du génie génétique analyse un projet précis.

Errare humanum est. Pourtant, aucune indulgence envers eux pour ce point.

Tu as peut-être raté le passage de la dépêche qui explique que, lorsque les auteurs ont finalement sollicité l’avis de leur comité d’éthique (à la demande du symposium S&P 2021), ils ne lui ont pas fourni une version suffisamment détaillé de leur protocole.

Alors, certes,

• il peut s’agir encore d’une erreur, mais là ça commence quand même à faire beaucoup (« oups, on a pas pensé à demander au comité d’éthique, c’est bête. Ah ben re-oups, on a oublié deux ou trois trucs quand on lui a finalement demandé, c’est ballot. ») ;
• on ne sait pas si le comité d’éthique aurait atteint une conclusion différente s’il avait eu tous les détails — possiblement non vu que ce comité a semble-t-il une conception très restreinte de son propre rôle, et ne se pense compétent que pour les questions de recherches biomédicales.

Mais quand même. Venir s’insurger du traitement réservé à ces pauvres malheureux auteurs qui ont juste fait une erreur, personnellement je trouve ça gonflé.

Surtout quand on voit que Kangjie Lu semble très bien capable de rebondir, vu qu’après cette affaire il a trouvé le moyen de co-présider un symposium international sur l’éthique en sécurité informatique ! Pardonne-moi de ne pas m’apitoyer sur son sort.

(Personnellement à choisir je m’apitoyerai plutôt sur Additya Pakki, dont on risque de se souvenir que ses patchs ont fait re-surfacer l’affaire en avril 2021 alors même qu’il n’avait rien à voir avec le projet “hypocrite commits”, et qu’en définitive son seul tort est surtout d’avoir choisi un directeur de thèse aux pratiques douteuses.)

En attendant, on s'attaque aux auteurs principalement sur leur erreur, et non sur leur malversation. Et ça oui, ça me pose problème. […] Par contre, le bidonnage, tout le monde s'en fou. Ils ont été manipulateurs, trompeurs, etc…

Tu te rends comptes que tu fais valoir ce point sous ce qui est à ma connaissance le seul article de tout le web francophone à présenter le bidonnage (il y a une section entière consacrée à ça, au même niveau que les problèmes éthiques), et à accuser ouvertement les auteurs de fraude scientifique ?

Je ne peux pas parler pour ce qui se passe en France.

Mais au Royaume-Uni, tu serais à côté de la plaque sur plusieurs points.

Au moment de la soumission du projet, le formulaire comporte un certain nombre de cases : le projet comporte-t-il des expériences sur les animaux, sur les humains, sur des OGM

Un dossier destiné à un comité d’éthique n’est en aucun cas un formulaire avec des cases à cocher. Il faut détailler, justifier chaque point. On parle d‘un dossier d’une quinzaine de pages minimum, et encore pour les projets les plus simples.

Étant donné le nombre de projets, cette validation est seulement réglementaire; c'est un jeu de questions-réponses. Si l'expérience fait intervenir des sujets humains, il faut leur faire signer le formulaire XY

Non. Juste non. Le dossier est lu, et soigneusement. Il circule entre tous les membres du comité préalablement à la réunion, et si dès ce moment-là quelqu’un a des remarques à faire le porteur du projet est contacté pour lui donner une chance de fournir des précisions et de régler les éventuels problèmes le plus tôt possible (idéalement avant la prochaine réunion du comité).

Ça doit dépendre des organismes, mais vu les délais serrés, il me semble très improbable qu'un comité se réunisse et évalue un par un les projets en les lisant.

C’est pourtant précisément ce qui se passe. Sauf qu’idéalement, une bonne partie de la discussion sur un projet donné a déjà eu lieu en amont de la réunion (par email ou téléphone), donc à ce stade déjà le comité réuni n’a typiquement plus grand’chose à faire sur chaque dossier.

Selon le type de comité, le porteur du projet est invité à assister à la réunion pour le moment où son dossier est évalué, ce qui lui permet de répondre aux questions du comité et d’éclaircir tout point qui n’aurait pas déjà été réglé préalablement.

Cette invitation du porteur du projet est à ma connaissance systématique pour les projets revus par les comités d’éthiques nationaux du NHS (cas de la plupart des projets de recherches biomédicales impliquant des patients). Pour les comités d’éthiques locaux propres à chaque université (voire chaque département d’une université), je crois que c’est laissé à la discrétion de chaque comité.

Du coup, quand certains d'entre vous imaginent qu'il existe des gens payés pour lire les projets de recherche et donner un avis individualisé sur chaque projet après discussion collégiale, j'ai vraiment l'impression qu'on vit dans des mondes parallèles.

C’est exactement l’impression que j’ai en te lisant, parce que c’est exactement ce qui se passe au Royaume-Uni. Je n’ai pas d’expérience en la matière en France, mais j’ai du mal à croire que cela puisse être si différent. En tout cas j’espère que ça ne l’est pas.

Pour ce que ça vaut, en France j’ai par contre une expérience (vieille d’il y a dix ans, d’accord) avec la commission du génie génétique (qui doit valider tous les projets impliquants des organismes génétiquement modifiés), et c’est comparable avec ce que je décris ci-dessus concernant l’approbation éthique au R.-U. À savoir, un long dossier très détaillé (pas une succession de case à cocher) qui est examiné en détail en commission. Ça me rend d’autant plus sceptique sur le fait que l’approbation éthique en France se déroulerait comme tu le prétends.

Mais le côté "falsification", on a l'impression que tout le monde s'en fout alors que c'est là qu'ils devraient être le plus emm****dé (car là, c'est volontaire et donc prémédité).

Là on est d’accord.

Je pense personnellement que les chercheurs sont secrètement bien contents que tout le monde se soit focalisé sur leurs manquements à l’éthique, et qu’à côte de ça leurs manquements à l’intégrité (aka fraude, ou scientific misconduct si on pense que « fraude » est un grot mot) soient passés complètement sous silence.

Seuls les organisateurs du S&P 2021 mentionnent brièvement la fraude (sans jamais utiliser ce mot) dans leur communiqué annonçant le retrait du papier. Ni les chercheurs, ni leur université n’ont dit mot à ce sujet (la Linux Foundation non plus mais ça à mon avis c’est plus compréhensible, c’est pas tellement leur problème).

À ma connaissance aucun autre article paru au sujet de cette affaire n’a jamais mentionné la fraude. Merde, ça a même été une de mes motivations principales pour finir cette dépêche.

Et même pour les super-débutants qui font vraiment parfois un peu n'importe quoi […], ben je prends plaisir à les guider

C’est exactement ce que Dan Carpenter a tenté de faire suite à un des patchs de « George Acosta ».

Carpenter a correctement vu le problème introduit par le patch (or it lead to a use after free), et au lieu de simplement le rejeter d’office ou de l’ignorer, il a tenté d’expliquer à son auteur quel était le problème et lui a suggéré une meilleure façon de corriger le problème de départ.

Il pensait aider un contributeur honnête, alors qu’en recevant son message « George Acosta » n’a probablement eu pour seule réaction que « Ah merde, il a vu le problème l’enfoiré. »