Atelier : les outils collaboratifs (Muriel Foulonneau et Frédéric Clavert)

CR par Frédéric Clavert

Il existe un consensus sur la nécessité des outils collaboratifs, mais de nombreux points d’interrogation se maintiennent: quels outils pour quelle communauté ? Comment identifier une communauté ? Certains sites collaboratifs échouent car la communauté n’existaient pas ou n’a pas apprécié les outils mis à disposition. Comment tenir compte de la vie des communautés ? En effet, les membres d’une communauté évoluent, parfois quittent la communauté alors que de nouveaux arrivent. Une communauté peut également disparaître. Comment intégrer différents acteurs au travail collaboratif ? Le public d’un outil collaboratif doit intégrer des chercheurs, des ingénieurs des acteurs publics, des bailleurs de fonds, des étudiants, des entreprises… Bref, ces outils doivent intégrer différentes cibles et l’ensemble du « petit peuple de la recherche », voire au-delà pour certains projets (projet eLab de M. Foulonneau et du CRP Tudor).

Au delà, il faut s’interroger sur la notion de partage du savoir scientifique. Utiliser un outil collaboratif amène à partager. Quand partager et pourquoi ? Y a-t-il un risque à partager ? Que partager ? Les limites techniques doivent être cernées, en particulier le manque d’interopérabilité des outils d’annotation (cf. projet OpenAnnotation). Quand, dans le cycle de publication, doit-on partager ses données ?

En outre, le travail collaboratif peut faire émerger une nouvelle littérature grise numérique, via les blogs scientifiques, twitter, facebook… Comment la prendre en compte dans l’évaluation et le cursus des acteurs de la recherche ? Et le travail collaboratif peut-il faire émerger un contenu différent du travail de recherche classique ?

Quelle est la méthode à employer pour mettre au point un outil collaboratif ? (études utilisateurs, personas, questionnaires…). Il ne faut pas oublier d’adapter les infrastructures de l’outil au besoin du projet. Qui doit mettre en œuvre l’outil collaboratif (chercheur, ingénieur de recherche… les deux ?)

Enfin, quelles sont les conséquences du travail collaboratif ? les hiérarchies au sein des communauté évoluent-elles avec un outil collaboratif ? Les pratiques de la recherche, les méthodologies changent-elles ?

Le débat est commencé par Marin Dacos (CLEO), estimant que certains projets peuvent être, à leur bénéfice, “low cost” en utilisant des outils bien rodés (Flickr, par exemple). La discussion s’est ensuite orientée vers la question de la cyberinfrastructure, par le biais de l’analyse des projets ANR : chaque projet prévoyant son outil, il y a dispersion des moyens, des financements de chaque projet.

À ce sujet, Ian Johnson (Sydney), estime qu’il faut faire les choses petit-à-petit, une marche à la fois (méthode des petit-pas selon F. Clavert, méthode itérative pour une vraie expression scientifique).

La discussion a également mis en exergue certains risques liés aux cyberinfrastructures de la recherche: la centralisation, l’enfermement des usages, le fait que certains projets risquent de ne pas être compatibles avec la cyberinfrastructure… une cyberinfrastructure universelle, valable pour tous les projets SHS relève peut-être du fantasme…

En fait, il s’agit peut-être de se mettre d’accord sur des bases de travail, avec un socle suffisamment souple pour accueillir un grand nombre de projet. Il faut s’obliger à faire appel aux savoir-faire d’autres chercheurs (travailler avec des sociologues, par exemple, pour cerner les besoins des utilisateurs).

Sur la question du risque lié aux infrastructures, Marin Dacos évoque la notion de rapport de force avec les cyberinfrastructures : il faut promovoir des solutions qui ont fait leur preuve. Et ce d’autant plus que la multiplication des moteurs (firefox pour zotero, omeka, et d’autres) provoque une dispersion, peu cumulative et donc pas collaborative.

Hervé Le Crosnier rappelle que la multiplication des projets d’outils et des développements d’outils relève aussi du fait qu’en informatique, il faut réinventer tous les jours, pour garder le savoir-faire et le développer. Parfois, l’interopérabilité des données est plus importantes que le développement de l’outil (« l’encodage plutôt que le code » selon Marin Dacos). Ce dernier rappel l’importance du projet PLUME qui permet de diffuser les informations et les savoir-faire. Il en appelle à participer à ce projet.

Emmanuelle Morlock s’interroge : y a-t-il vraiment un problème de foisonnement et d’absence d’interopérabilité ? L’usage permettra aux choses de se décanter. Faire quelque chose utile pour soi, rajouter un peu de temps pour que ce soit utilisable pour d’autres et partager. Dans ce cadre a été évoqué l’importance du Linked Data. Marin Dacos remarque toutefois que développer un programme avec l’idée d’ouvrir son code, donc de travailler aussi pour les autres, avec développement de routines d’installation et de documentation peut prendre 80 % en plus du développement, pour se prendre des « patates », car souvent fusent les critiques. Se pose, une nouvelle fois pendant THATCamp, le problème de répartition du travail : ceux qui reprennent le logiciel doivent participer à ce travail qui permet d’ouvrir le logiciel aux autres.

Pour le manifeste, cet atelier a retenu :

• l’architecture modulaire est nécessaire, car elle permet une plus grande souplesse d’adaptation de chaque projet ;
• moins d’efforts sur le code, insister sur l’encodage des données, donc sur leur interopérabilité ;
• la métaphore de l’échelle, des petits pas ;
• nous sommes ignorant d’où nous allons ;
• communiquer sur ce qui fonctionne (PLUME / Blog Zotero francophone).
• pourquoi une inertie en France ? Travaillons ensemble avec les gens qui veulent le faire et veulent construire une communauté ;
• le code a une valeur universitaire, peut-être scientifique.