On a beaucoup parlé ces derniers temps de fraude scientifique. Toutes les « affaires » concernaient, me semble-t-il, la biologie ; j’aimerais ici esquisser ce qui pourrait relever de la fraude dans ma discipline, l’informatique, et des disciplines connexes.

En premier lieu, un avertissement. Lorsque l’on parle d’erreurs dans des publications scientifiques, on glisse parfois un peu rapidement de l’idée d’erreur à l’idée de fraude. Or, il est tout à fait possible de commettre des erreurs en toute bonne foi. L’idée d’erreur elle-même mérite d’être nuancée : l’erreur scientifique, du moins dans mon domaine, consiste souvent non pas en quelque chose de vraiment faux, mais plutôt en quelque chose qui n’a pas la portée que la publication laisse supposer ; je vais expliciter cela.

Mon sentiment général est d’ailleurs qu’il existe toute une gradation entre la publication la plus honnête et rigoureuse et la publication franchement frauduleuse, passant par diverses négligences, choix avantageux de cas d’études, exagérations, désir de ne pas trop explorer ce qui pourrait conduire à d’autres résultats… Tout ceci est d’ailleurs encouragé par le système de publication scientifique, de recrutement, de promotion et de financement des chercheurs ! Si j’écris un article où j’explique que ma méthode n’est qu’une amélioration de travaux précédents, produisant un gain modeste de performances et que je le soumets à une revue ou conférence de premier plan, il sera probablement rejeté ; si au contraire je présente mon approche comme très novatrice avec un gain important de performances, il sera accepté ; or de l’un à l’autre il n’y a qu’une question de présentation et de choix d’exemples... L’accumulation de publications « cotées » me permettra d’avoir un bon dossier pour demander une promotion, un financement, etc. (même si d’autres facteurs sont considérés).

Revenons à la question des publications en informatique. Il est périlleux de parler en généralités sur une discipline qui recouvre en réalité des sous-disciplines si diverses ; toutefois je ne pense pas me tromper en disant qu’un article ou une thèse d’informatique comprend en général :

  1. Une introduction (longue dans le cas d’une thèse, parfois très brève dans un article) présentant le domaine, les questions que l’on entend soulever ou résoudre, l’intérêt technologique, social ou économique de ces questions et des solutions apportées, les travaux scientifiques connexes, et un résumé des principales contributions.

  2. Des contributions théoriques : descriptions d’algorithmes, preuves de correction ou de complexité de ces algorithmes, définitions mathématiques, théorèmes mathématiques et preuves de ces théorèmes, etc.

  3. Une évaluation pratique, typiquement des chronométrages de temps de calcul sur une batterie d’exemples.

Voyons ce qu’il en serait des fraudes pour chacun de ces aspects.

Introductions d’articles

Dans les présentations de domaines scientifiques dans les rapports et thèses on trouve parfois des plagiats. En effet, ces présentations portent sur des généralités et non sur les travaux spécifiques de l’auteur, et il est tentant de reprendre des textes, schémas etc. trouvés dans d’autres documents. Il est toutefois périlleux de copier-coller depuis des documents trouvés sur le Web, car il est alors facile de retrouver les passages qui semblent « rapportés » ; cette recherche est d’ailleurs automatisée par des logiciels tels que Compilatio, installés dans les universités. Il est bien entendu plus délicat de retrouver la paraphrase ou l’inspiration non créditée. Il ne faut également pas crier au plagiat ou à l’« auto-plagiat » (reprise par un même auteur de textes identiques dans plusieurs publications, afin de multiplier celles-ci sans apport scientifique) si les textes similaires ne concernent que des définitions standard… il n’y a pas trente-six façons de dire, par exemple, qu’un treillis est un ensemble ordonné dont toute paire d’éléments admet une borne supérieure et une borne inférieure !

La présentation des questions résolues est parfois trompeuse (sciemment ou non). En effet, on peut très facilement faire apparaître un résultat comme ayant une portée plus importante qu’il n’en a réellement, par exemple en ne précisant pas certaines restrictions ou définitions ; par exemple, on peut dire que le résultat obtenu est « optimal », mais en ne précisant pas la notion d’optimalité ou complétude utilisée ou les hypothèses sous-jacentes, qui seront plus loin dans l’article. Le lecteur qui se limiterait à l’introduction pourrait en concevoir une idée plus haute des résultats que la réalité.

Les possibles applications technologiques, notamment dans les thèmes à la mode du moment, sont parfois exagérées. J’ai une fois été dans un comité de programme d’une conférence où nous avons accepté un article par ailleurs scientifiquement solide, mais à condition que les auteurs ôtent de leur introduction des perspectives d’applications trop distantes et incertaines.

L’exposé des travaux voisins est un art difficile. Si l’on oublie un travail pertinent, on risque de se faire des ennemis des auteurs vexés et de leurs amis ; cela peut être rédhibitoire. Toutefois, si l’on mentionne des travaux équivalents, la contribution pourra être considérée comme trop mineure. Il s’agira donc de rendre hommage à des travaux tout en expliquant que ce que l’on fait est mieux ou différent, mais si l’on dit trop que c’est mieux on risque de vexer, donc le mieux est d’expliquer que c’est différent. Tout ceci peut être un peu trompeur.

Résultats théoriques

Il paraît a priori difficile de tricher dans des preuves mathématiques : ce n’est pas comme une expérience que l’on peut inventer. Toutefois, il est possible de se tromper...

Un raisonnement mathématique est très rarement parfaitement rigoureux au sens que l’on expliciterait chaque recours à une définition ou à une règle de déduction. En effet, des preuves mathématiques rédigées à ce niveau de détail seraient interminables et incompréhensibles pour un lecteur humain (c’est d’ailleurs pourquoi, si on veut en arriver là, on a recours à un « assistant de preuve », un outil informatique qui vérifie la preuve à son plus haut niveau de détail). Une preuve mathématique usuelle passera au contraire rapidement sur des étapes de raisonnement que tout lecteur du domaine pourrait reconstituer et détailler si besoin.

Parfois, cela se voit à certaines tournures : quand l’on fait une hypothèse « sans perte de généralité », on veut que ramener le cas général au cas particulier étudié se fait par une transformation et une justification suffisamment simples pour que le lecteur ne voie pas de problème à ce qu’on les omette. Dans certains cas, on dira qu’une preuve est la même qu’une autre mutatis mutandis, c’est-à-dire « en changeant ce qui doit être changé »…

Parfois, malheureusement, on commet une erreur. On pense qu’une étape est évidente alors qu’il y a un problème, on prend des quantifications logiques dans le mauvais sens, on se mélange dans les indices, on applique un théorème en oubliant une de ses hypothèses… Georges Gonthier cite même le cas d’un théorème dont la preuve est fausse car s’appuyant sur une erreur d’imprimerie !

Si l’on peut se tromper ainsi de toute bonne foi, on peut certainement le faire volontairement. Il doit également exister des cas intermédiaires, du style « ce résultat semble se déduire de tel résultat dans tel article, et nous n’allons pas chercher la petite bête en vérifiant toutes les conditions au risque de tomber sur un os technique qui prendra du temps à résoudre » — autrement dit on ne commet pas sciemment une erreur, mais on est sciemment négligent au risque d’une erreur.

Pour prendre un exemple concret, il m’est arrivé d’évaluer un article où, dans une démonstration, les auteurs invoquaient un théorème « trop beau pour être vrai ». Je suis allé voir en bibliothèque le livre d’où ils tiraient ce résultat, j’ai vu qu’ils avaient omis en le citant une hypothèse, non vérifiée dans leur cas. Erreur volontaire ou involontaire ?

Par ailleurs, même si un résultat théorique est prouvé rigoureusement, il reste la question de son interprétation informelle, qu’il est possible d’exagérer ! En effet, un résultat théorique porte sur un modèle d’une partie de la réalité, modèle qui peut être imprécis voire passer à côté de l’essentiel, partie de la réalité qui peut être trop restreinte…

Résultats pratiques

Il s’agit ici en général de programmer les algorithmes proposés, puis de les essayer sur des jeux d’exemples afin d’évaluer leur efficacité et leur précision en pratique.

On peut être surpris du recours à une évaluation pratique dans le cas de l’algorithmique, puisque l’on fournit déjà des preuves mathématiques. Il y a plusieurs raisons pour ceci. Tout d’abord, deux algorithmes apparemment équivalents du point de vue de certaines analyses de complexité peuvent avoir des coûts très différents en pratique. Par ailleurs, dans certains domaines on sait que la complexité pire cas de tous les algorithmes est prohibitive, voire qu’il n’existe pas de procédé algorithmique qui fonctionne dans tous les cas : aussi on voudra distinguer différentes propositions suivant ce qui se passe sur des cas réalistes, quelle proportion de cas seront résolus en combien de temps.

Une première difficulté est donc de choisir des cas d’essais réalistes, au sens de représentatifs de ce que les utilisateurs du procédé algorithmique proposé voudraient pouvoir résoudre. Parfois on prend des exemples « synthétiques » plus ou moins aléatoires, mais rien ne dit que ceux-ci soient représentatifs des situations réelles ! Il est tentant de proposer comme exemples « représentatifs » ceux sur lequel l’algorithme proposé dans l’article est particulièrement efficace…

La constitution de bibliothèques d’exemples (SPECint, SMT-LIB etc.) pallie en partie ce problème mais en crée d’autres. En effet, les chercheurs visent alors à résoudre les exemples dans la bibliothèque et non ceux des situations réelles… On a même vu des concepteurs tenter de détecter certains des exemples standard et dans ce cas appliquer des procédures spéciales, un peu comme les véhicules Volkswagen qui détectaient qu’ils étaient sur le banc d’essai antipollution et appliquaient un programme spécial de carburation.

Se pose ensuite le problème de la comparaison aux autres méthodes. Ceci suppose soit de se procurer d’autres outils implantant les méthodes auxquelles on se compare (outils souvent indisponibles, non maintenus, sans documentation…), ou d’implanter soi-même les méthodes en question. Il est alors possible d’implanter ces méthodes de façon stupide, inefficace, tandis que la nouvelle à laquelle on les compare sera implantée intelligemment…

Ainsi, même en rapportant sincèrement des résultats d’expériences réellement conduites, il est possible d’induire le lecteur en erreur, du fait de la non représentativité de ces expériences. Il y a, à mon avis, toute une continuité entre les petites omissions et le choix d’exemples plutôt favorables à la nouvelle méthode et l’invention complète de résultats, comme on peut malheureusement le soupçonner dans le cas de certains articles.

De nos jours, certaines conférences d’informatique suggèrent fortement, voire dans certains cas imposent, la soumission d’artefacts, c’est-à-dire d’un composant logiciel intégrant les outils et les exemples permettant à une équipe d’évaluateurs de reproduire les résultats de l’article, voire d’essayer la méthode sur d’autres exemples. Bien entendu, ce n’est pas une solution totale, mais cela met un peu de rigueur dans le processus.

En conclusion

Il y a toute une gradation entre l’honnêteté complète et les résultats fabriqués. Certaines décisions sont parfaitement humaines et explicables : par exemple, si une méthode a une faiblesse, on va éviter de trop la souligner afin de ne pas donner des verges pour se faire battre… D’une façon générale, cela fait partie de l’exercice que de manifester un certain enthousiasme pour le nouvel algorithme proposé. De là l’on glisse à ne plus mentionner les faiblesses, à exagérer les points positifs, à sélectionner les exemples, à omettre de préciser certaines conditions de mesure… La pente est facile !