davidbgk
/
larlet-fr-david-cache

title: Folklore ou fait scientifique, comment les différencier
url: http://blog.institut-agile.fr/2010/11/folklore-ou-fait-scientifique-comment.html
hash_url: 799be21bdc20aa5d5bf8e5b3be3d190e

Ce qui est ennuyeux avec les opinions, c'est que chacun a la sienne. Et vous trouverez tout et son contraire. "Le développement par les tests élimine les bugs", affirme l'un. "Le développement par les tests fiche en l'air votre architecture", prétend l'autre. La connaissance ne peut pas se diffuser <i>que</i> par le biais des blogs, organes d'opinion s'il en est, faute de quoi tous les débats vont durer éternellement. L'intérêt du travail des scientifiques, c'est de trancher.<br />
<br />
<b>Comment fonctionne le discours scientifique</b> <br />
<br />
Bruno Latour, l'un des observateurs les plus passionnés du véritable travail que produit la science, et aussi l'un des plus attentifs à le débarrasser de ses mythes et images d'Epinal qui l'entourent, nous donne plusieurs pistes pour mieux évaluer le statut d'une recherche <i>en cours</i>, qui n'a pas encore abouti; ce qu'il nomme une <a href="http://controverses.ensmp.fr/">controverse</a>.<br />
<br />
(J'ai découvert les écrits de Bruno Latour lorsqu'on m'a recommandé de lire <a href="http://www.amazon.fr/dp/2707121207">Aramis ou l'Amour des Techniques</a>. Ce livre a totalement changé ma façon de voir les projets informatiques, bien qu'il concerne un autre domaine technologique: les transports en commun. Depuis, je le recommande vivement à tous les chefs de projets, architectes, ingénieurs et managers de mon entourage; c'est un de mes livres indispensables. Il révèle Latour comme un observateur tenace et minutieux, avec une incroyable capacité à aller au fond des choses dans le domaine des sciences et techniques. Il se lit comme un roman, ce qui ne gâte rien.)<br />
<br />
Latour attire notre attention en particulier sur la <b>structure modale</b> du discours scientifique. Cette expression barbarbe désigne quelque chose de tout simple. Vous partez d'un simple énoncé: "L'eau bout à 100 degrés." Une modalité est quelque chose qui vient, sans modifier cet énoncé mais en le complétant, lui donner un statut différent: "Si je me souviens bien, l'eau bout à 100 degrés" exprimerait de l'incertitude. "Tout le monde sait que l'eau bout à 100 degrés" au contraire renforce l'autorité du discours. "Les scientifiques savent que l'eau bout à 100 degrés" aurait une connotation légérement différente, celle d'un savoir pas nécessairement partagé par le commun des mortels.<br />
<br />
Dans la pratique des sciences, une <b>publication</b> joue le rôle d'une (très longue) modalité. Un chercheur souhaite affirmer une conclusion: "l'eau bout à 100 degrés". Il doit dans un premier temps, c'est la convention de sa profession, la présenter avec des pincettes: "sous réserve des questions de validité soulevées ci-dessus, et au vu de nos mesures expérimentales il nous semble possible d'affirmer que l'intervalle de confiance à 95% situe le point d'ébullition d'H20 à 100 degrés plus ou moins 0,01 dans les conditions expérimentales". Le reste de la publication (du "papier") tient lieu d'autant de précautions qui visent à relativiser l'énoncé final.<br />
<br />
Une expérience ou une étude n'étant jamais suffisante pour asseoir un fait scientifique, d'autres "papier" vont poursuivre ces travaux, qu'ils soient écrits par le même chercheur ou par ses confrères. Il faut pour cela que les travaux initiaux soient <i>intéressants</i>, ce qui est souvent un premier filtre; sans doute l'immense majorité des "papiers" publiés n'est jamais cité par d'autres scientifiques. La <b>citation</b> joue donc un rôle capital dans l'acquisition du statut de "fait scientifique".<br />
<br />
La citation est elle-même une modalité, souvent complétée par un degré de confiance: "Un travail préliminaire de Dupont (2001) suggère que l'eau bout à 100 degrés. Nous présentons une réplication utilisant un équipement différent mais aboutissant à des conclusions qui semblent confirmer ce résultat, avec une légère variation." L'accumulation des citations d'un "papier" donné est souvent une mesure de son importance, et si l'énoncé fini par se confirmer il établira la <b>paternité</b> du fait en question.<br />
<br />
Ce que Latour met en lumière c'est que <b>l'établissement d'un fait scientifique s'accompagne de la disparition progressive des modalités</b>. Ainsi l'étape suivante est-elle: "De nombreuses études ont mis en évidence que le point d'ébullition de l'eau se situe autour de 100 degrés (Dupont 2001, Durand 2002, Dupont 2003, Bogdanoff 2010), mais avec de légères variations; nous montrons que ce point d'ébullition dépend de la pression atmosphérique et selon quelle équation." Un peu plus loin encore, on commence à ne plus citer les auteurs: "Il est désormais établi que l'eau bout à 100 degrés à pression atmosphérique normale; nous étudions les effets de l'adjonction de sel dans l'eau."<br />
<br />
Au stade ultime de l'acceptation d'un fait scientifique, celui-ci est d'une part débarrassé de toute modalité ("l'eau bout à 100 degrés") mais plus important encore <b>devient opérationnel pour produire d'autres connaissances, ou des effets techniques utiles</b>: "pour obtenir une température de 100 degrés nous portons de l'eau à ébullition". (Pour des exemples plus réalistes, lisez <a href="http://www.amazon.fr/dp/2707148482"><i>La vie de laboratoire</i></a> de Latour et Woolgar.)<br />
<br />
Evidemment, ce qui fait de ce jeu de citations une démarche proprement scientifique, c'est son caractère expérimental et contradictoire; cette réduction des modalités n'est pas inexorable, et une étude préliminaire largement citée peut se voir mise en défaut par des études postérieures.<br />
<br />
L'autre cas de figure, c'est que le prétendu "fait" ne se débarrasse jamais tout à fait de ces modalités; il reste indéfiniment entâché de soupçon, et si personne ne s'y intéresse assez pour y donner suite dans de nouvelles publications, il tombe dans l'oubli, ou pire, s'incruste dans le discours collectif à l'état de <b>folklore</b>.<br />
<br />
<b>Que sait-on sur la productivité des programmeurs?</b><br />
<br />
Prenons par exemple un "fait" largement cité dans le monde informatique, celui selon lequel "la productivité des programmeurs varie dans un rapport de 1 à 10 (ou 5, ou 20) entre les moins bons et les meilleurs". C'est un énoncé surprenant, ne serait-ce que pour ses implications en entreprise: les écarts de salaires entre programmeurs, par exemple, ne sont certainement pas de cet ordre.<br />
<br />
A quand remonte cet énoncé? Coincidence amusante, la <a href="http://portal.acm.org/citation.cfm?id=362858">première étude</a> à faire état de ces disparités remonte apparemment à 1968. C'est une "vraie" étude scientifique, qui au départ cherche à comparer, dans deux conditions expérimentales, la performance de programmeurs<b> confrontés à une tâche de mise au point (debugging)</b>. Les temps de programmation sont collectés au cours de l'étude mais n'en sont pas le sujet principal. L'étude trouve de façon statistiquement significative que l'une des deux conditions de travail ("online" c'est à dire en mode interactif avec le compilateur) améliore légèrement la performance. Elle note par contre comme une observation surprenante la très grande magnitude des écarts entre les "scores" obtenus par les différents sujets de l'étude, sur diverses mesures de performance.<br />
<br />
Cette étude fait rapidement l'objet de diverses critiques, à la suite desquelles on pourrait penser que d'autres recherches vont tenter de confirmer ou d'infirmer ces observations, activité dont on devrait retrouver, quarante ans plus tard, des traces conformes à ce qu'explique Latour: réduction des modalités et transformation en "fait scientifique".<br />
<br />
En fait il n'en est rien. Aussi surprenant que cela puisse paraître, <b>quarante ans après</b> le résultat initial, l'énoncé reste aujourd'hui accompagné de ses modalités: chaque fois que j'ai l'occasion de lire ou d'entendre cette observation, c'est sous la forme "<b>de nombreuses études montrent que</b> la productivité varie dans un rapport de 1 à 10 (ou 5, ou 20)".<br />
<br />
Non seulement il n'a pas perdu ses modalités, mais ce "fait" ne s'est <b>toujours pas transformé en quelque chose d'opérationnellement utile</b>. On ne sait pas aujourd'hui comment exploiter cette "trouvaille", par exemple en définissant des critères de recrutement qui nous permettraient d'écarter les programmeurs "fois 1" et garder préférentiellement les "fois 2 à 10". Par contre, personne ne se prive de citer cette "observation" pour étayer un discours essentiellement idéologique: "de nombreuses études montrent ceci, donc vous devriez suivre mes conseils".<br />
<br />
<b>Comment tricher avec les citations</b><br />
<br />
L'un des essais les mieux renseignés sur le sujet est celui de Steve McConnell, "<a href="http://bit.ly/9Rffwb%20">The Origin of 10x</a>". Publié en 2008, ce billet publié sur son blog explique le titre de ce dernier, "10x programming". Il s'agit bien entendu d'une référence aux variations de productivité. McConnell reconnaît que l'étude de 1968 a été très critiquée, mais il affirme que ses résultats ont été confirmés:<br />
<blockquote>the general finding [...] has been confirmed by many other studies of professional  programmers (Curtis 1981, Mills 1983, DeMarco and Lister 1985, Curtis et  al. 1986, Card 1987, Boehm and Papaccio 1988, Valett and McGarry 1989,  Boehm et al 2000).</blockquote>Rien ne fait plus "scientifique" que cette litanie de citations. Mais qu'en est-il en regardant de plus près?<br />
<ul><li>L'étude de Curtis de 1981 porte sur 60 programmeurs confrontés à nouveau à une tâche de mise au point et non de programmation.</li>
<li>L'article de Curtis de 1984 n'est pas une étude, mais un appel à mieux intégrer les sciences cognitives dans le génie logiciel. (Au demeurant je rejoins Curtis à ce sujet, mais j'y reviendrai.)&nbsp;</li>
<li>La citation de Mills 1983 se réfère à un livre regroupant divers essais sur la productivité, essentiellement des retours d'expérience et articles d'opinion, mais aucun qui porte sur une réplication de l'étude originelle.</li>
<li>De même pour DeMarco et Lister 1985, il s'agit du célèbre "Peopleware", pavé jeté dans la mare d'une certaine forme de management par la presssion malheureusement toujours en vogue de nos jours; les seules "études" relatées portent sur des compétitions de programmation organisées par les auteurs, dans des conditions peu contrôlées (les participants devaient réaliser les exercises proposés sur leur lieu de travail et pendant les heures de bureau).</li>
<li>La référence Card 1987 n'est pas une publication scientifique mais le rapport d'activité d'un laboratoire privé, où apparaissent quelques tableaux de synthèse dont aucun ne semble directement confirmer "des écarts de productivité de 1 à 10"</li>
<li>La référence Boehm et Papaccio 1988 est un travail de synthèse qui cite plusieurs autres publications, la seule qui soit citée sur les variations de productivité étant... l'étude de 1968!</li>
<li>Je n'ai pas pu vérifier la référence Boehm 2000 (de toutes façons, un livre sur COCOMO et non une publication scientifique)</li>
<li><b>Une seule</b> de ces références reproduit réellement le résultat d'origine mais indirectement, c'est Valett 1989, rapportant une étude de 1982 qui mesure la productivité en nombre de lignes de code (une approche fortement critiquée depuis) et fait apparaître des disparités dans un rapport de 1 à 8 sur de "petits" projets (moins de 20K lignes) et dans un rapport de 1 à 20 sur les gros projets. Comme il s'agit d'une citation d'une citation, presque aucun détail sur la méthode de collecte de données n'est disponible.</li>
</ul>Dans l'ensemble le tableau n'est guère encourageant: McConnell détourne le mécanisme de la citation scientifique et ne cherche qu'à donner de l'autorité à un énoncé qui ne la tient que d'une ou deux études préliminaires. (Je n'ai pas fait le travail critique équivalent quant aux recherches citées par McConnell sur les variations de productivité entre équipes. Malheureusement,<b> un travail critique prend beaucoup plus de temps qu'il n'en faut pour émettre des assertions mal étayées</b>, une asymétrie qui explique peut-être l'état de nos connaissances dans certains domaines.)<br />
<br />
<b>Pourquoi reste-t-on dans le folklore?</b><br />
<b><br />
</b><br />
Pour moi le verdict est clair, la prétendue observation "scientifique" sur l'ordre de grandeur des variations de productivité individuelle relève du <b>folklore</b>, des éléments d'opinion non confirmés qui se transmettent et se perpétuent pour des raisons plus culturelles que rationelles. (Je ne prétends pas qu'il n'y a pas de variations de productivité de cet ordre: je dis simplement que ce "fait" n'est pas démontré, et qu'on ne sait pas quoi en faire.)<br />
<br />
L'une des raisons à cela est qu'on n'est pas en mesure de cerner avec assez de précision la notion de "productivité". A l'origine, on avait tendance à mesurer en lignes de code. Avec le développement de "langages de haut niveau" on a sévèrement remis en cause cette mesure de productivité, puisqu'ils permettaient précisément de faire la même chose en moins de lignes. On a tenté de leur substituer les points de fonction, qui s'avèrent compliqués et peu utilisés par la profession. Mais la vraie question à poser est celles des <b>hypothèses qui sous-tendent la notion de "productivité"</b>.<br />
<br />
Par exemple, considérons-nous qu'une productivité ne peut être que positive ou nulle? C'est une hypothèse battue en brèche par la notion de "<a href="http://www.software-thoughts.com/2009/08/net-negative-producing-programer.html">net negative productivity programmers</a>": des membres d'une équipe qui non seulement n'apportent pas une contribution à la productivité mais <i>détruisent</i> celle des autres intervenants.<br />
<br />
Faisons-nous la différence entre les <i>efforts</i> et les <i>résultats</i>? Un programmeur peut très bien sembler improductif parce qu'il fournit peu de travail, mais s'il est à l'origine d'une idée innovante qui permet de <i>ne pas coder</i> plusieurs fonctionnalités complexes, sa contribution est d'une grande valeur.<br />
<br />
Une notion importante dans les sciences sociales et cognitives est celle de "construct validity", c'est à dire de répondre à la question: ce que nous mesurons a-t-il une existence réelle, et est-il réellement reflété dans les mesures avec lesquelles nous avons choisi de l'opérationnaliser? (Consultez par exemple l'article sur la <a href="http://fr.wikipedia.org/wiki/Psychom%C3%A9trie">psychométrie</a> de Wikipedia.) Ces questions semblent peu posées dans notre domaine; sans doute parce que nous ne nous inspirons pas des bonnes disciplines, et je reviendrai sur ce point prochainement.<br />
<br />
<b>Sortir du folklore</b> <br />
<br />
Au fil de la construction du <a href="http://referentiel.institut-agile.fr/">référentiel des pratiques Agiles</a>, le recensement des études empiriques pertinentes et, par le jeu des citations, les faits établis ou en construction dont elles dépendent permettra, c'est en tout cas mon intention, de définir les contours de ce que nous savons et de ce que nous ne savons pas encore sur le sujet.<br />
<br />
Ce travail ne s'arrête pas au référentiel: il est important aussi de recenser qui travaille sur ces sujets, en France notamment mais ailleurs également, et mettre en lumière les collaborations (pour l'instant encore trop rares) visant à rapprocher la communauté Agile et le milieu de la recherche. A plus long terme, l'Institut Agile cherchera à initier, ou en tout cas à apporter une contribution, à un espace permettant aux chercheurs de publier plus efficacement.