Le Design Participatif
Sous l'éclairage des sciences sociales, le « Design Participatif » (ou Participatory Design), envisagé dans le processus de création d'un logiciel, a pour but d'intégrer au mieux dans celui-ci les attentes des utilisateurs, principalement en matière de fonctionnalités et d'ergonomie.
« Une volonté politique disposant des ressources que fournit la science ne peut être éclairée qu'à partir de l'horizon d'un dialogue entre citoyens eux-mêmes, et c'est à eux que doivent retourner les lumières qui sont acquises. [1] »
La recherche en sciences sociales peut se pratiquer de différentes manières. Les chercheurs se fixent en effet des règles de conduite, des « lois théoriques et techniques générales d'application [qu'ils] sont d'accord d'adopter afin de fixer la norme selon laquelle leurs recherches doivent être conduites [2] ». Dans le cadre d'un processus de Design Participatif, le choix est posé dès le début d'un projet d'intégrer particulièrement au processus de développement les différents utilisateurs potentiels du logiciel qui sera issu de ce projet. Le Design Participatif consiste en une méthodologie qui tente d'établir un dialogue entre les développeurs et les utilisateurs finaux d'un logiciel, conçu comme un projet « co-construit ».
Premièrement – et de manière générale –, il nous semble inopportun de vouloir considérer que le chercheur en sciences humaines puisse se placer « hors du monde », extérieur à ce qu'il étudie et donc capable d'en « dévoiler » la réalité sociale par le truchement de la rationalisation ou de l'existence de mécanismes inconscients [3]. De plus, dans les recherches où le Design Participatif est mobilisé, il n'est ni nécessaire ni souhaitable de s'engager dans des interprétations théoriques de la situation sociale en question. Au contraire, considérant ici que les concepteurs ne sont pas plus compétents dans le domaine d'utilisation du logiciel que ses futurs utilisateurs, ceux-ci doivent faire preuve d'humilité et, comme le souligne Boltanski, « prendre au sérieux » ces derniers, particulièrement leurs arguments, leur activité critique, leurs « justifications » sur le sujet [4]. Plus que des objets d'étude, les usagers sont ici des « experts d'usage » disposant de connaissances plurielles et personnelles qui doivent être notre source principale d'information ; c'est donc d'abord de cette posture épistémologique et pratique que surgit notre volonté de faire participer les utilisateurs à la conception logicielle.
Deuxièmement, il faut souligner que les questions qui se posent lors du développement d'un logiciel sont des questions d'ordre technologique. Or, il apparaît que la technologie est en elle-même un opérateur social. La technologie est liée aux acteurs qui l'utilisent et lui donnent son rôle, faisant de la « chose » un « objet » [5]. Mais encore, les objets technologiques (comme tous les autres, d'ailleurs) disposent d'une capacité actancielle propre. Ces acteurs non-humains s'associent, résistent ou se soumettent, bref, « ils n'arrêtent pas de dépasser ceux qui les construisent [6] ».
« Ces êtres mesurés [les objets], en nous imposant la nécessité qui est inscrite en eux, ordonnent et orchestrent nos conduites. Ils jouent ainsi, par la contrainte qu'ils font peser sur nous le rôle que Durkheim reconnaissait aux normes sociales supra-individuelles inscrites dans le firmament de la conscience collective. [7] »
En d'autres termes, l'introduction d'un nouvel acteur non-humain, d'une nouvelle technologie, n'est pas un acte neutre et sans effet. La technologie n'est pas un pur objet matériel mais aussi une organisation sociale [8]. La question à se poser n'est donc pas simplement : « Quelle technologie en vue de réaliser le projet de société que nous voulons ? », « car la construction technologique et la construction de la société sont inséparables » [9]. Plus que ça, à la suite de Roqueplo, il nous paraît primordial d'envisager la négociation du « développement » technologique dans tous ses aspects et ce, dès son élaboration. Cette négociation avec ses futurs usagers peut alors se faire à trois niveaux : au niveau des techniques elles-mêmes, au niveau des conditions de leur implémentation et au niveau des conséquences de tels changements technologiques [10]. Il s'agit en effet d'envisager ces différents niveaux dans la mesure où « les moyens influent sur la poursuite des fins » [11]. Autrement dit, ce n'est pas parce que le débat sur les orientations à prendre a été effectué que les moyens pour y arriver sont neutres. Au contraire, ils impliquent toute une organisation de la société. Le choix des moyens n'est pas indifférent ; c'est pourquoi le dialogue doit être institué dans toutes les étapes de l'élaboration de l'objet technologique et ce à tous les niveaux. C'est donc, en deuxième lieu, de cette posture démocratique que surgit notre volonté de faire participer les utilisateurs au développement logiciel.
Globalement, nous considérons donc que la meilleure manière de tenir compte de cette double réflexion est de mettre en place un processus de Design Participatif que l'on peut comprendre, comme nous l'avons déjà dit, comme la mise en œuvre d'une méthodologie qui tente d'établir un dialogue entre les développeurs et les utilisateurs finaux afin de co-construire le processus technologique en question. C'est avec ces « experts d'usage » que nous entendons interagir afin de recueillir la pluralité de leurs impressions, avis, craintes et des justifications qu'ils avancent. Ainsi, nous entendons apporter au projet une dimension sociale en adéquation avec les attentes des futurs utilisateurs. Si, comme nous le posons, les choix technologiques ont un impact social, nous pensons que c'est avec la société visée qu'il faut les élaborer.
De manière très concrète, nous pouvons identifier trois grandes phases dans la mise en œuvre d'un processus de Design Participatif. Premièrement, il s'agit de s'informer précisément sur le sujet en question, par une revue de la littérature scientifique, des entretiens avec les experts du domaine ou toute autre technique qui pourrait améliorer nos connaissances du sujet. En deuxième lieu, il faudra évaluer les attentes des utilisateurs dans une phase exploratoire extrêmement ouverte durant laquelle l'objectif sera d'identifier la pluralité des arguments développés par les futurs utilisateurs. Enfin, ceux-ci doivent être impliqués dans un dialogue plus précis, éclairé des informations de la phase exploratoire, afin de construire un consensus sur les choix technologiques à élaborer et à adopter.
[1] Jürgen Habermas, La technique et la science comme « idéologie », Paris, Gallimard, 1973, p. 121
[2] Autrement dit, en fonction du paradigme auquel ils adhèrent in Bruno Frère et Marc Jacquemain, « Fonder ou représenter : de l'apriorisme et du constructivisme en sciences sociales. Quelques clefs de lecture en guise d'introduction », in Marc Jacquemain et Bruno Frère (dir.), Épistémologie de la sociologie, Paradigmes pour le XXIe siècle, Marc Jacquemain et Bruno Frère (dir.), Ouverture Sociologique, De Boeck, p. 11
[3] Luc Boltanski, « Nécessité et justification », Revue économique, Volume 53, n°2, 2002, pp. 277-278
[4] Luc Boltanski, op. cit., p. 283 et Frédéric Claisse et Marc Jacquemain, « Sociologie de la critique : la compétence à la justification » in Marc Jacquemain et Bruno Frère, op. cit., pp. 138-139
[5] Philippe Roqueplo, op. cit., p. 16
[6] Frédéric Claisse et Marc Jacquemain, op. cit., p. 146
[7] Luc Boltanski, L'amour et la justice comme compétences. Trois essais de sociologie de l'action, Paris, Métailié, 1990 in Rémi Barbier et Jean-Yves Trépos, « Humains et non-humains : Un bilan d'étape de la sociologie des collectifs », Revue d'anthropologie des connaissances, n°1, 2007, p. 4
[8] Gérard Fourez, La construction des sciences, De Boeck Université, Bruxelles, 1996, p. 181
[9] Ibid., p. 183
[10] Philippe Roqueplo, op. cit., p. 177-188
[11] Gérard Fourez, op. cit., pp. 178-179
