La problématisation (traduction 1) n'est pas seulement une opération qui aide à passer d'une expérience vers un cahier de charges. C'est également un moyen d'intéressement, d'enrôlement des développeurs. La robustesse du collectif de code, son engagement et la qualité de travail peut défendre de ce travail de problématisation. Le défi doit être identifié à la fois en tant que problème social et en tant que challenge technique. Comme le souligne Alexey Sidorenko, « il est très important, pour n'importe quel développeur, et surtout si c'est un bon développeur, si il est indépendant mais avancé et spécialisé sur un truc précis, c'est d'avoir un défi, et le problème des activistes des ONG c'est que quand ils formulent des tâches, ils ne peuvent pas toujours formuler ce défi pour les développeurs » [entretien avec Alexey Sidorenko, CEO de la Serre, organisateur de nombreux hackathons de la Serre]
L’intéressement des développeurs s’opère donc par un travail de réduction d’une grande cause sociale vers quelque chose de codable. Les ONG participant aux hackathons se chargent de préparer des soi-disant « problem statements » qui fait ressortir les contours possibles d’une mise en technologies. Les développeurs que j’ai interviewés et observés, soulignent l’importance d’avoir ce challenge technique.
Comment peut-on « coder », par exemple, l'inégalité homme-femme ? Ou la pauvreté ? Les premières difficultés consistent donc à trouver les moyens de concrétiser le défi et d'imaginer des solutions d’architectures informationnelles qui correspondraient à la tâche.
La présence des porteurs de cause dans l'équipe, leur collaboration et le dialogue permanent avec les développeurs, la transparence des différentes étapes de développement du projet sont autant des conditions importantes pour développer un outil potentiellement traduisible vers le grand monde. Comme le souligne Milena, membre de Transparency International, organisatrice et membre du jury des hackathons « Hack Against Corruption » :
“Another step which I found it was quite difficult to get these people who wrote these statements to work with the developers. Not only explain what the problem is and then leave, but also really during the hackathon work together to be sure the problem is addressed the way that the problem owner wants it to be addressed. So you know there is this cooperation and communication between the area expert and the developer and I think it's quite challenging to get them to speak the same language in such a short time spent. Again it is not necessarily how the problem is written initially but really the cooperation throughout the process...” [entretien avec Milena, Transparency International]
83
En décrivant la démocratie dialogique comme différente de la démocratie représentative, Callon et al. (2001) ont analysé le rôle joué par les publics dans cette première traduction, du
« grand monde » vers le laboratoire : ils devaient s'assurer que le problème traduit était toujours « le leurs ». Dans la démocratie représentative justement, la participation directe est remplacée par une représentation, dans le sens presque pictural du terme, par une projection de ce qui pourrait être l’avis des publics (des instruments comme sondages d'opinion sont alors utilisés pour remplacer la parole des citoyens). Or, dans un modèle d’une démocratie dialogique, les publics ont, selon les auteurs, l’accès au processus (ou à la procédure) de traduction très en amont, au moment où les défis sont sélectionnés, reformulés, problématisés, transposés vers le microcosme d'un laboratoire. Ce modèle de dialogue est basé sur une réversibilité et une transparence des étapes de traduction, où les profanes peuvent influencer le cours de travail technique. Je parlerai, à mon tour, d’un travail itératif et non-linéaire de conception, caractérisé par des retours et des va-et-vient entre le code et l’expérience.
Mon enquête montre que la participation des publics dans le codage permet de consolider l’équipe autour du défi. Reuben Katz, l'organisateur du Hack4Good, souligne la capacité des porteurs de cause de mobiliser l'équipe, enrôler les développeurs et structurer leur travail :
« If they [participants of the hackathons] come and put the idea, it’s because they probably have experienced that in in their own lives, whether it was themselves, their friends or family members… So they are able to express that aim to others and then others believe in that aim. For example one of the teams on the event built an app to help villages in Africa sell their products […] So... there’s a guy52 who comes and says hi, I’m from Ivory Coast and the village I came from builds beautiful things but nobody knows about them, so… What was remarkable is that he was able to express that vision and gather the entire team together around this vision and they were really motivated ; they rallied behind him, they stayed all night, he did not leave the event for two days… » [entretien avec Reuben Katz].
La vision d’un problème est donc capable de tenir ensemble une équipe d’acteurs aux expertises multiples, de devenir intermédiaire dans l’organisation du travail. Mais, comme le soulignent les acteurs interviewés, les porteurs de cause doivent participer à la fabrication de l’outil non seulement à l’étape de la problématisation, mais aussi au cours du développement technique. Ils peuvent garantir qu’il existe toujours un lien entre le problème comme il est vécu par les acteurs et le problème comme il a été réduit et transformé en cahier des charges.
52 Il s'agit de Hyacinthe, l'auteur du projet « Yaklolo », application pour les artisans africains, qui doit faciliter la recherche des clients pour acheter les produits de leur travail.
84
Or, la communication entre porteurs de problèmes et développeurs n’est pas toujours lisse.
Il existe de nombreux problèmes de différence d’expériences, de langages, de visions.
Milena, organisatrice d'une série de hackathons « Hack Against Corruption », mise en place par Transparency International avec l'aide du Random Hack of Kindness, parle de ces difficultés de coopération et des efforts nécessaires pour faciliter la traduction :
“Another thing is again the cooperation… NGO activists, they know very well their field but they really have no idea about technologies. And they work with people that know technology but know very little of the field, so how can you bridge this gap and get these people to work actively together? What tends to happen is that hackers take the problem statements, they go and work alone, and come back with a solution that not always matches the reality. So you have to make constant check between the problem owners and the developers to make sure that the process is a negotiated process. The developers come with expertise and creativity and everything, but also the problem owner understands how it is build and how he can contribute” [entretien avec Milena, TI]
Les organisateurs des hackathons civiques distinguent, eux, deux groupes d'acteurs distincts, et c’est bien la collaboration entre les deux groupes qui est au cœur du défi organisationnel.
Ces deux groupes sont distincts tout d'abord en fonction de l'expertise qu'ils ont. Peuvent-ils maîtriser le code ? Ou connaissent-ils le problème ?
Un des problèmes de certains développeurs, selon Milena, consiste à prendre le défi (« problem statement ») comme un cahier de charges et s'isoler pour travailler dessus seuls, sans avoir de dialogue avec les porteurs de problème. Tandis que les porteurs de problème, eux, ont tendance de proposer des solutions techniques inefficaces, trop coûteuses, irréalisables, inadaptées. Les organisateurs essaient alors de s’assurer que ce processus soit véritablement dialogique, qu'il y ait des négociations entre les deux groupes (« negociated process »).
La négociation lors d’un hackathon est un processus itératif, non-linéaire, qui avance et recule. Il ne s'agit pas de prendre des décisions tranchées, mais des micro-décisions, faire des adaptations, des tests. Etant donné la temporalité spécifique du hackathon, les acteurs sont obligés de faire des compromis entre leur idée initiale exposée pendant le pitch et ce qui est techniquement possible.
Les projets développés pendant les hackathons civiques gardent en eux les traces de ces va-et-vient permanents entre l'écriture du code (qui se déroule souvent en silence, d'ailleurs) et les discussions, où le collectif essaie de projeter l'utilisateur « dans » le prototype d'application, le faire se balader dans les parcours imaginés, modéliser des situations d'usage, trouver des moments où ça pourrait bloquer… et revenir vers le code pour le modifier encore et encore.
85
Afin d’équilibrer ces deux communautés, de les faire dialoguer et d’arriver à des projets
« négociés » (donc, ouverts à des mises en cause et contributions de la part de tous les membres de l’équipe) les modérateurs et organisateurs des hackathons civiques mettent en place des dispositifs de facilitation variés.