Développer depuis le terrain
Quand une ingénieure et un designer partagent leurs réflexions sur les implications méthodologiques de leurs pratiques de production de logiciels destinés à l’enseignement et la recherche.
Chronique
Afin de préparer leur intervention au FOSDEM 2020 (en vidéo en bas de page), Audrey Baneyx et Robin de Mourat se sont interrogés sur les pratiques au coeur du médialab. En mobilisant les valeurs d’interdisciplinarité, d’artisanat numérique et de design situé propres au laboratoire, ils partagent ici leurs questionnements, leurs intentions, et leurs doutes sur les implications méthodologiques de leurs pratiques de production de logiciels destinés à l’enseignement et la recherche.
R : Donc, d’après nos premières discussions, cette présentation au FOSDEM porterait sur la spécificité des démarches de fabrication d’outils numériques dans un laboratoire interdisciplinaire ?
A : C’est aussi comme cela que je le formulerais. Il s’agirait de brosser un portrait de nos modes de production en tant que laboratoire de recherche, en contraste avec cet autre hétérogène que nous appelons “l’industrie”. Ce serait intéressant, pour nous-mêmes, et pour le public de développeurs de cet évènement, de qualifier la spécificité de nos manières de faire et l’intérêt qu’elles ont pour les enjeux liés à notre contexte, celui de la recherche en Sciences humaines et sociales (SHS).
R : Dans ce cas, il faudrait peut-être d’abord décrire les spécificités de notre équipe ? Cette dernière est doublement interdisciplinaire : on y trouve des “ingénieur.e.s”, des “designers”, des “sociologues”, mais chaque individu a également souvent une formation et une expérience hétérogènes du point de vue des disciplines et de métiers passés. Notre argumentation devrait alors démontrer en quoi cette hétérogénéité influe sur le développement des logiciels de recherche.
A : Pour ma part, cela s’est traduit, par exemple, dans l’évolution de mon rôle dans l’équipe au fil des années. J’ai joué le rôle de cheffe de projet scientifique, d’ingénieure, de documentaliste, de chercheuse, d’enseignante, de médiatrice… c’est une vraie richesse pour articuler les enjeux autour des développements, être capable de voir un projet de conception selon plusieurs perspectives.
R : Oui, l’interdisciplinarité permet de fabriquer des rôles médiateurs dont tu es l’exemple : documenter, tester, enseigner, pratiquer - des outils de recherche. Par ailleurs, le contexte scientifique fait que nous ne sommes pas dans une logique d’identification de marché ou de besoin, mais plutôt de proposition et d’expérimentation.
A : Tout à fait. Des outils comme Hyphe ne répondent pas vraiment à un besoin préexistant et identifié ; au contraire, ils proposent de nouvelles méthodologies et typologies de recherche par leur existence même et invitent les communautés de recherche à se les approprier. Il ne s’agit pas de créer un besoin artificiel mais de proposer de nouveaux espaces d’invention méthodologique.
R : En ce sens, il est vrai que nos méthodes ne sont pas très conventionnelles du point de vue du design et du développement de produits numériques. Nous ne travaillons pas selon des séquences linéaires classiques telles qu’on les pratiquerait dans des unités de service (en enchaînant une “étude du besoin” avec une “preuve de concept” puis une “industrialisation”…), ni d’ailleurs exactement selon ce qu’on appelle maintenant des “méthodes agiles” où les rôles sont clairement et durablement définis. Notre manière de faire échappe à une doctrine méthodologique claire, et passe davantage par l’articulation très étroite et la redistribution fréquente entre expérimentations de recherche, expériences pédagogiques, et développements de logiciels au long court.
A : Une manière élégante de dire que c’est un joyeux bazar ! Nous pourrions tenter de suivre un ou deux “outils” du médialab et voir les différentes phases qui ont conduit à leur production en tant “qu’outils” ? Je propose Hyphe Browser et Fonio. Qu’en dis-tu ?
R : D’accord. En faisant ce travail, on voit que les outils suivent des trajectoires complexes et sont la trace d’une série d’activités hétérogènes avec des enchaînements non linéaires : expériences en classe, bricolages dans le cadre de projets de recherche, expérimentations techniques…
A : Ces trajectoires révèlent une multiplicité d’opérations de traduction d’une phase à une autre (“réutilisation”, “formalisation”, “facilitation”, “expérimentation”, “implémentation/application”, “réappropriation”...) pour arriver à la stabilisation d’un “outil” à un moment donné.
R : À ce titre, le fait que nous enseignons et recherchons en plus de la conception est très important dans l’articulation entre ces différents moments ! J’utilise souvent les “outils” que j’ai développés pour mes propres activités de recherche et d’enseignement par exemple. Et, à l’échelle de l’équipe, nous discutons régulièrement avec Thomas Tari et d’autres enseignants du laboratoire de leurs usages en classe, de manière plus ou moins informelle et naturelle - au détour d’un couloir, autour de notre table de déjeuner collectif, etc. Dans ce contexte de proximité et d’hybridation, les évolutions et les modifications de nos logiciels se font de manière organique, dans un aller-retour constant entre le “terrain” (de recherche, d’enseignement) et le “bureau” de design & développement.
A : D’autant plus qu’il y a aussi le cadre du METAT, cette séance mensuelle où nous aidons et conseillons des membres de la communauté de recherche (ingénieur.e.s, doctorant.e.s, étudiant.e.s, chercheur.e.s…) de tous horizons ! C’est l’occasion de leur faire tester nos outils et d’observer en direct comment se passe leur prise en main, d’envisager ou de bricoler de nouvelles procédures, fonctionnalités, formes. Nos “outils” ainsi utilisés sont alors parfois améliorés, parfois “bifurqués” dans des versions alternatives plus adaptées à un besoin spécifique ...
R : … voire parfois délaissés au profit d’un autre logiciel plus adapté ! Être continuellement plongés dans les situations de recherche nous invite à ne pas être arrêtés sur les outils en tant que tels. Le fait de ne pas travailler dans un contexte industriel et commercial rend tout attachement excessif aux “produits” que nous faisons inutile... bien que, il faut l’avouer, ce soit parfois une tentation ! Pour ma part, j’ai passé des centaines voire des milliers d’heures sur certaines de mes productions logicielles. Pour autant, je ne veux pas en devenir l’avocat ou le promoteur, car ce serait un investissement coûteux aux conséquences peu pertinentes pour mes/nos autres activités. Du point de vue scientifique, notre travail de valorisation consiste plutôt à apprendre à bien parler (ou écrire) de nos expériences de fabrication, et les interroger comme des lieux de réflexion et de problématisation. Nos productions sont destinées à être “utiles” à d’autres chercheur.e.s bien sûr, mais c’est dans leur faire que nous trouvons un intérêt intellectuel propre. Et cela est permis par la grande porosité de la division des tâches à l’œuvre dans notre manière de produire des logiciels.
A : En ce sens le mot qui me vient à l’esprit pour caractériser la manière dont nous travaillons est “artisanal”. Qualifier notre pratique “d’artisanat numérique” restitue notre attention à gérer souplement la division des tâches et des responsabilités, à se méfier de toute automatisation méthodologique, et à maintenir le caractère situé de nos activités de design et de développement, au plus près des pratiques scientifiques et méthodologiques.
R : C’est aussi un bon terme pour pointer certains de nos doutes récurrents, comme notre labellisation en tant que producteurs “d’outils” : à cet égard, le passage d’une situation d’équipement local à des solutions partageables, stables et “industrielles” prend beaucoup de temps, et nous éprouvons parfois les limites de notre non-spécialisation et de notre composition hybride à cet égard. Dans les composantes les plus techniques de l’équipe, la dimension d'administration et de gestion infrastructurelle que peuvent impliquer nos outils ouverts est une préoccupation constante. Il s’agit de rester toujours dans un équilibre entre des activités d’expérimentation par le développement et pour la recherche - ce qui est le cœur de notre activité - et la production et la maintenance de produits numériques industriels - ce qu’implique le fait de proposer des “outils” ouverts à tous.
A : J’ajouterais à cela les problèmes d’usage liés à la décontextualisation de nos productions quand elles deviennent des “outils génériques” utilisés dans d’autres environnements. Il est notamment difficile de faire comprendre les enjeux qui sont souvent précis et élaborés. Si l’on prend notre dernier logiciel Tesselle par exemple, il s’agit d’un outil qui se situe à la croisée entre l’annotation d’image et la publication web de documents visuels de recherche. L’outil ne fait pas qu’offrir des fonctionnalités : il propose aussi une certaine manière d’écrire, de conduire une recherche, et de la publiciser notamment sur le web. Chaque outil propose une manière de faire de la recherche, une vision et une méthode. Et cette spécificité (dirions-nous idiosyncrasie ?) est consubstantielle du contexte d’élaboration de nos productions, mais elle est difficile à gérer quand nous les présentons comme des “outils” disponibles en un clic, faciles d’accès, sans plus de contextualisation.
R : Oui. Pour la présentation, que dirais-tu de dessiner chacune des formes de contextualisation dans lesquelles est baigné le développement de nos outils ? Nous aurions d’abord les rapports entre les différentes composantes du labo :
A : Il faudrait aussi restituer les trajectoires hybrides de nos productions, entre pédagogie, recherche et outillage propres à notre manière d’envisager les pratiques de développement :
R : Puis on devrait rendre compte de la distribution des rôles dans les prises de décisions afférentes à un outil en particulier :
A : Oui très bien ! Reste à écrire la présentation qui permettra de partager nos réflexions !
Iframe /static/Developing_from_the_field(1)_36cc19cf-d883-44a6-b455-522094f7a5df.html
Audrey Baneyx & Robin de Mourat