• Aucun résultat trouvé

Le test de la borne de covoiturage (ecov)

Chapitre 3 ;;;: Les coulisses en amont, l’élaboration des scripts de l’interface

4. La simulation, ou l’incarnation de l’interface dans les coulisses

4.3. Le test de la borne de covoiturage (ecov)

La conception de la borne de covoiturage est également l’occasion d’analyser des situations de modalisation au cours desquelles les professionnels simulent l’usage de la borne par « substitution d’identité physique ». Pendant le training, les professionnels jouaient les « membres du public » invités à une réunion de concertation. Ici, les professionnels proftent de la présence physique de l’objet borne dans une situation de travail pour en jouer les utilisateurs. La présence de l’objet fait partie de l’ancrage du cadre modalisé dans le cadre primaire de la situation de travail.

Une premiTre simulation a lieu en amont du lancement de l’expérimentation, pendant une réunion dans les locaux du fournisseur de bornes. Trois personnes, en plus du chercheur en observation, participent à cete réunion ;;;: un chef de projet du fournisseur de borne, le directeur technique d’ecov et un designer partenaire. La réunion a lieu sur une terrasse, atenante aux locaux, où sont disposés diférents modTles d’horodateurs. Le fournisseur présente à ses interlocuteurs celui à partir duquel est conçu le prototype de borne de covoiturage. A ce moment, le parcours utilisateur de la borne n’est pas encore clairement défni, notamment à cause d’une incertitude sur le procédé de validation du ticket. Deux scénarios sont discutés ;;;: la validation peut se faire grâce à un lecteur de QR code34 intégré à la borne, ou bien par la saisie d’un code sur l’application (c’est cete derniTre solution qui est fnalement choisie, comme nous l’avons vu au chapitre précédent). Ces deux scénarios ont chacun leurs avantages et leurs inconvénients ;;;: la validation par lecture de QR code est plus rapide à efectuer, mais elle nécessite d’ajouter un module à la borne déjà trTs contrainte en termes de place et de consommation énergétique ;;;; la saisie d’un code est plus fastidieuse pour l’utilisateur mais elle s’efectue grâce à l’application existante. Dans les deux cas, il y a un problTme de confit d’usage à résoudre ;;;: qu’il s’agisse d’utiliser le lecteur de QR code ou l’application, l’utilisateur doit intervenir sur la borne sans risquer de faire atendre l’automobiliste, alors qu’un autre utilisateur est potentiellement en train d’utiliser la borne pour formuler une demande. La startup envisage donc d’installer à chaque station de covoiturage une deuxiTme borne

exclusivement dédiée à la validation. Le designer présent à la réunion chez le fournisseur cherche des alternatives à ce scénario qui lui semble peu compréhensible pour les usagers. Une discussion a lieu devant la borne. Alors que le designer propose de metre le lecteur de QR code sur le devant de la borne, le directeur technique réagit ;;;:

DT ;;;: Y a le mec il est en train d’utiliser l’écran, il est sur son compte, il y a son nom, et toi tu arrives et tu lui dis ;;;: « excuse-moi je dois valider mon ticket. Est-ce que c’est acceptable, ça ;;;?

Le directeur technique mime la scTne en se plaçant devant la borne, il joue l’usager en même temps qu’il met en récit sa simulation. Il intTgre son interlocuteur, le designer, à ce jeu fctionnel, en lui donnant le rôle d’un deuxiTme usager (« toi tu arrives ») et imagine l’interaction entre les deux (« tu lui dis ;;;: « excusez-moi je dois valider mon ticket »). Dans la foulée, il pose une question rhétorique visant à évaluer la fction qu’il vient d’inventer ;;;: « est-ce que c’est acceptable, ça ;;;?). Comme dans le cas du test du formulaire, les deux phases identifées dans le cas du training (la modalisation appelée « mise en situation » et la mise en récit appelée « debrief ») se superposent sans parenthTses pour marquer le passage de l’une à l’autre.

Qelques mois plus tard, à la fn du comité de pilotage de janvier 2016 réunissant une quinzaine de représentants du consortium, c’est-à-dire à la veille du lancement des premiTres stations de covoiturage, a lieu une autre simulation d’usage ;;;: la directrice des transports du Val d’Oise teste le prototype de borne fraîchement arrivée dans les locaux de la startup. Elle est entourée de l’équipe, ils discutent ensemble du parcours utilisateur qu’elle est en train d’appliquer. Les échanges montrent qu’elle réalise sans cesse des allers-retours entre la casquete d’usager de la borne et celle de professionnel évaluant la borne. Elle commence par suivre la procédure d’inscription, pour laquelle il faut choisir un mot de passe. Elle s’exclame ;;;:

Dir ;;;: Ah zut, je me suis trompée dans mon mot de passe [...]. Faut que je trouve des mots de passe dont je me souvienne aprTs.

A ce moment elle s’exprime en tant qu’utilisatrice de la borne. En les sortant de leur contexte du test dans les locaux de la startup, on pourrait tout à fait les atribuer à un usager en train de s’inscrire afn de pouvoir se déplacer grâce au service de covoiturage. En revanche, elle commente, un peu plus tard ;;;:

Dir ;;;: Ça fait partie du genre de chose qu’il faut dire avant. Et ;;;:

Dir ;;;: Il va falloir améliorer.

Dans ces extraits, elle évalue la procédure d’inscription. En employant le verbe « falloir », elle prescrit des actions à l’équipe pour améliorer la procédure. Elle s’exprime

en tant que professionnelle testant un outil. Sans cesse, elle passe ainsi du cadre primaire au cadre modalisé de maniTre à formuler une évaluation en temps réel de la mise en scTne inscrite dans la borne.

Le test de la borne constitue donc un moment de fotement entre les rôles d’usager et de professionnel, par des allers-retours incessants. Dans l’extrait qui suit, la premiTre personne du singulier renvoie, dans la premiTre proposition, au professionnel, et dans la deuxiTme et la troisiTme, à l’usager ;;;:

Dir ;;;: Ça me paraît assez clair, j’accepte, je saisis le code avant de monter, etc.. Non c’est bien ça. TrTs bien.

En disant « ça me paraît assez clair », la directrice approuve la procédure ;;;; lorsqu’elle ajoute « j’accepte, je saisis le code », elle commente son action à la borne. Elle passe d’une posture professionnelle à une posture d’usager ;;;; puis en disant « Non, c’est bien ça. TrTs bien », elle bascule à nouveau dans l’évaluation professionnelle de la borne. Au cours de ce deuxiTme test, la partenaire chargée de jouer l’utilisateur formule des prescriptions au cours du test, destinées à la startup. Elle imagine une situation à venir au cours de laquelle la startup améliore l’interface avant que celle-ci ne soit mise en service pour les utilisateurs fnaux (Illustration 41).

Les simulations constituent donc des immersions fctionnelles dans des interfaces médiatisées ou en face-à-face particuliTrement incarnées ;;;: elles permetent d’intégrer Illustration 41 : Schéma représentant le processus de test de la borne de covoiturage

Conclusion

Le travail de préparation réalisé en coulisses consiste à anticiper le travail d’interface en en élaborant le script. Pour pallier l’absence des comédiens qui se produiront dans l’interface à venir, les professionnels inventent plus ou moins consciemment des personnages fctifs, au moyen de diférents vecteurs d’immersion. Dans certains cas, certains comédiens professionnels de l’interface sont présents dans les coulisses. C’est le cas du training où certains professionnels font semblant de jouer leurs propres rôles d’« intervenant » et de « modérateur », tandis que leurs collTgues endossent celui du « public ». Dans d’autres cas, aucun des comédiens de l’interface ne sont présents dans les coulisses. Le script en cours d’élaboration doit alors prévoir un moment où les commanditaires délTguent à des outils ou à des professionnels présents à l’interface le soin d’inviter les usagers à endosser leur rôle.

Les professionnels metent donc au point une fction de l’interface à venir et des coulisses à venir qui sont nécessaires à sa mise en scTne. Par ailleurs, les participants justifent la vraisemblance de leurs fctions en s’inspirant spontanément d’expériences passées similaires, ce qui laisse penser que les interfaces passées, au-delà de leurs restitutions formelles dans le cadre d’enquêtes notamment, ont des implications bien plus larges et imprévisibles sur le travail en coulisses. Ainsi de multiples liens communicationnels se metent en place entre les situations d’interface et de coulisses. Certains contribuent à instaurer le script en cours d’élaboration en reliant entre eux les éléments composites, encore virtuels, destinés à le réaliser. D’autres liens, en revanche, surgissent de maniTre spontanée, au gré des associations d’idées qui se forment dans l’esprit des participants. Ces derniers mobilisent des situations similaires mais a priori totalement déconnectés du script en cours d’élaboration, en les détachant des logiques qui ont déterminé leur genTse, et en les metant au service des logiques actuelles. J’analyse cela plus en détail dans le chapitre suivant.

Chapitre 4 ;;;: Les coulisses en aval, la mise en récit des