[MUSIQUE] [MUSIQUE] Je m'appelle Yoan Ollivier, de l'agence Plausible Possible, je suis designer de service, et je travaille principalement pour des collectivités. L'expérimentation ça va intervenir plutôt en fin de parcours, au moment où un projet est relativement décidé et où on va le mettre à l'épreuve du réel, donc, de ce point de vue-là, ça veut dire qu'en tant que designer, on va intervenir surtout sur la mise en place d'un cadre expérimental, c'est-à-dire essayer de définir quels sont les éléments que l'on va tester ou non, on ne va pas tester l'ensemble d'un service, mais on va aussi tester les éléments les plus saillants, les plus représentatifs, ceux qui vont faire le plus de sens dans la modification que le projet va avoir sous l'usage du service proposé. On pourrait dire qu'il y a à peu près trois types d'acteurs. Il y a les personnes qui organisent le test, ils peuvent être les designers ou les services qui sont concernés, les personnes qui sont les opérateurs, les gens qui vont faire marcher le service, et les utilisateurs, ceux qui pour qui le service est fait. En tant que concepteurs, on va travailler avec ces trois types de personnes dans un premier cas principalement sur la manière dont on est capable de cerner le périmètre d'un test d'expérimentation pour pouvoir le laisser à disposition et vérifier leurs enseignements. Les opérateurs que l'on va embarquer, parce qu'ils vont devoir eux-mêmes changer leur pratique, leur manière de faire, et être les acteurs de ce test. Dans la plupart des cas, c'est les opérateurs qui vont jouer un jeu de rôles pour essayer pour remettre en situation le test pour pouvoir en tirer les enseignements. Donc, ils sont à la fois, les acteurs et les capteurs de ces enseignements. Et enfin, on va avoir les utilisateurs qui sont les personnes qui nous donnent, somme toute, la plupart des retours, qui sont les personnes à qui on fait vivre le test et qui nous expliquent comment ces rapports fonctionnent. Et dans tous les cas, l'objectif va être d'essayer de réussir à interroger une diversité de situations de manière à vérifier la robustesse de l'expérimentation qu'on va avoir. Si on a que les mêmes types de retours, on va être dans une situation qui nous donnera des enseignements qui risquent d'être relativement pauvres. Donc l'objectif, c'est bien réussir à capter quels sont les différents types d'acteurs qu'on va pouvoir questionner, quels sont les différents de contextes. Dans un premier cas, c'est bien de délimiter cette diversité-là, mais aussi savoir la restreindre, parce que si on fait une expérimentation sur un trop grand nombre de sites ou de situations, on a aussi le risque se de perdre dans une expérimentation qui perdra du sens, parce qu'elle essayera de tout questionner. Ensuite en terme de points de vigilance, l'un des point important, c'est nous ne sommes pas en train de tester la réalité, l'expérimentation est toujours un système de conception en tant que telle, donc elle doit pouvoir nous ramener les enseignements. Au moment où l'on fait une expérimentation, il faut bien savoir que, on a de grandes chances que ça ne fonctionne pas et laisser la place à cette erreur-là et laisser le temps de pouvoir comprendre les erreurs que retire l'expérimentation, font partie du champ de conception. L'expérimentation c'est un processus qui peut prendre du temps. Dans certains cas, certains éléments peuvent être testés très rapidement parce qu'on est sur une sorte de reconnaissance directe. La signalétique, l'information sont des éléments que l'on peut tester très rapidement. Par contre, les changements d'usages, pouvoir comprendre comment est-ce que dans un processus de suivi long, on est capable de pouvoir accompagner un changement entre l'état initial et l'état proposé. Cette transition, elle doit pouvoir être prise en compte et elle va déterminer la longueur de l'expérimentation qu'on va pouvoir faire. Une difficulté lorsqu'on lance une expérimentation, c'est d'être capable d'en donner la fin. Parce que par définition, on est sur des systèmes qui sont perfectibles et dans un monde rêvé de designers, ce serait une expérimentation permanente, qui serait plutôt inconfortable pour les utilisateurs. De fait, il faut qu'on soit capable de déterminer en amont quelle sera la date de fin d'une expérimentation. Pour choisir cette date de fin, généralement ça pose la question de l'élément dont je parlais tout à l'heure qui est la durée de l'expérimentation, on va questionner cette durée-là, mais la fin de l'expérimentation va arriver au moment où on a l'ensemble des informations qu'on souhaitait obtenir et dont la situation dans laquelle qu'on est capable de réagir et arbitrer par rapport à ça. L'expérimentation c'est pas une fin en soi, c'est un moyen qui doit nous permettre d'obtenir des enseignements du terrain, aux vues d'une solution proposée et de pouvoir en vérifier la résistance. L'expérimentation c'est pas un fait designer, on doit pas être l'acteur principal qui réalise l'expérimentation, il faut que ça soit pensé comme logique d'accompagnement dans lequel on va pouvoir suivre les opérateurs pour qu'ils puissent tester, comprendre. Et, en premier lieu, l'un des retours qui est le plus informel et qui est difficile à pouvoir capter, c'est ce retour et ce changement d'expériences et d'expertises qui auraient été vécus par les opérateurs après une expérimentation. Le deuxième point, c'est il faut pouvoir capter un ensemble d'informations aux vues d'une expérimentation, c'est-à-dire être capable de documenter, des photographies, des films, des témoignages. Ça va aussi être des retours documentés sous forme d'outils qui vont nous permettre de collecter les retours d'utilisateurs sur le changement de perception, est-ce que c'est mieux, moins bien, est-ce que on se sent plus à l'aise, est-ce que c'est plus fluide. La qualification des retours des utilisateurs va être important. Enfin, il y a une question qui est aussi quelles sont les données factuelles qu'on est capable de retirer, parce que si le design est souvent très orienté vers des questions de qualité, de qualitatif, il serait dommage de pas se priver du temps d'expérimentation pour avoir des retours qui sont chiffrés, et à ce moment-là, la question va être d'identifier quels sont les bons indicateurs qui font que l'expérimentation va nous donner des retours. Est-ce qu'il y a une augmentation du nombre de coup de téléphone entre avant et après l'expérimentation. Est-ce qu'on a diminué le nombre de mail, est-ce que l'on a augmenté la fréquentation d'un site, est-ce que l'on a diminué le retour et la fréquence de venues de quelqu'un dans un espace. C'est autant de questions qu'il va falloir chercher à identifier. Lorsqu'on va lancer une expérimentation dans le designer, on va travailler sur différents éléments. On va travailler cadre, on va travailler les objets de l'expérimentation, on va travailler les éléments de recueil de l'expérimentation, Lorsque l'on va travailler sur le cadre, c'est qu'on va définir quels sont les objectifs d'une expérimentation, à quoi elle va servir, qu'est-ce qu'elle va vérifier. De ce point de vue-là, il faut que chaque expérimentation, chaque élément de test, soit très circonscrit dans son espace et dans son temps de manière à bien tester la vérificateur d'un facteur, ou de deux au maximum, mais essayer d'être plutôt humble dans le choix des différents éléments test, de manière à pouvoir avoir des résultats effectifs. Quand on va travailler cette expérimentation dans le designer, soit on va être dans une logique de suivi, soit on va être dans une logique de prototypage. Lorsqu'on est dans une logique de prototypage, de fait, on va arriver avec des éléments tangibles, on va arriver avec des plaquettes qui sont des fausses plaquettes, on va transformer un accueil, on va travailler la relation et la liste de questions qui vont être faites par un agent, avec tous ces éléments de prototypes-là, ils doivent être vérifiés avec les équipes en amont, pour que le moment du test venu, ce soit quelque chose de fluide et d'agréable pour les personnes. Il n'y a rien de pire que de faire un test qui met en échec les opérateurs qui ont travaillé dessus. Enfin, c'est aussi poser la question très en amont de la manière dont on va collecter les informations et de la manière dont on va pouvoir restituer l'expérimentation. Est-ce que on a une caméra qui filme en temps continu l'évolution des transports. Est-ce que on fait des interviews après le test de différents utilisateurs. Est-ce qu'on a une grille de notation qui est uniquement utilisée par les opérateurs. C'est autant de questions mais qui doivent être réfléchies en amont en expérimentation de façon à ce qu'aux sorties de de l'expérimentation, qu'on ait bien les éléments qui soient intéressants à traiter et qui nous permettent d'outiller l'aide à la décision des personnes qui vont pouvoir réfléchir à la suite du service. La nature des tests, elle va être très différente en fonction des projets, on peut très bien tester des objets, tester des services ou tester des processus. En fonction de ces trois critères là, on est face à des degrés de changements et de modifications de l'existant qui sont assez différents qui font que le test est plus facile à réaliser. Lorsque l'on teste un objet ou un espace on est face à une réaction très directe de la part des usagers. En fait, il vont découvrir l'objet qu'on leur présente et il ne vont pas forcément se poser la question de sa nature. Est-ce qu'il y réponds ou non à a question, et c'est l'unique objectif qu'ils auront en tant qu'utilisateurs, et c'est le retour qu'ils vont faire. Lorsqu'on teste un service, on est face à une situation qui est plus dispersée dans le temps. On aura sans doute une information initiale, le changement d'un site web, le changement d'une plaquette, le changement d'une somme de petits éléments constitutifs du service, qui fait que le test va être relativement être plus complexe parce qu'on va devoir essayer d'insérer ces différents éléments dans un processus existant, et de voir comment est-ce qu'il des modifications. Donc on est face à un test qui, déjà sous entend, que l'on est déjà dans un processus de changement. Lorsqu'on va tester un processus, on est directement dans un processus de changement et c'est là toute la difficulté, c'est qu'en testant des modes de relations, on les fait vivre, et lorsqu'on les fait vivre, il y a forcément des crispations qui peuvent exister. [MUSIQUE]
