Conseiller en expérience utilisateur et formateur passionné
blogue
Catégories
3 juin 2008
Expérience utilisateur : une définition
Sur ma carte de visite, il est écrit « conseiller en expérience utililisateur ». Pour plusieurs, je suis « ergonome », ce qui est le cas. Cela dit, l'expérience utilisateur est un domaine beaucoup plus vaste que l'ergonomie ou l'utilisabilité. Mais qu'est-ce que l'expérience utilisateur au juste?
Il y a quelques semaines, Kim Auclair publiait un billet définissant l'expérience utilisateur comme étant « le terme désigné lorsqu’on donne le goût à l’utilisateur de revenir sur une interface numérique ». J'aime bien cette définition toute simple puisqu'une expérience utilisateur agréable incite à la répétition, que ce soit sur un site Web ou dans une boutique, un restaurant, etc.
Pour moi, l'expérience utilisateur, c'est l'émotion ressentie par un utilisateur lorsqu'il utilise un service (Web ou humain) dans l'atteinte d'un objectif. Se procurer un iPod et avoir l'air « cool », obtenir la meilleure paire de billets disponibles pour le spectacle de Louis-José Houde, impressionner un client important en l'emmenant manger dans un bon restaurant sont autant d'exemples d'objectifs.
L'expérience utilisateur n'est pas limitée au Web. Bien entendu, ce volet est important. Il donne souvent le ton à l'expérience utilisateur d'ensemble, mais il n'est pas seul. Par exemple, un produit acheté en ligne qui arrive endommagé à domicile gâche tout, même si ça s'est bien déroulé sur le Web. C'est comme un mauvais café qui sabote un excellent repas. Tout, je dis bien, tout est important dans l'expérience utilisateur.
L'expérience utilisateur d'ensemble est un savant assemblage de l'expérience :
- d'accueil,
- de sélection,
- d'achat,
- d'environnement,
- de livraison,
- de découverte,
- et bien entendu d'utilisation (ou de consommation).
Exemple 1 : Je veux un iPod!
Michael (toute ressemblance est fortuite) voit une publicité d'Apple à la télévision lui vantant l'iPod et iTunes. Répondant émotivement au design attrayant et « cool », Michael ne cesse de penser au iPod.
Afin d'en savoir plus, il visite le site Web d'Apple. La page d'accueil est simple. Le lien le menant aux iPods est bien en évidence.
Michael peut comparer les iPods et choisir celui qui répond le plus à ses besoins. L'ambiance du site est à l'image d'Apple, c'est-à -dire épurée. On y parle un langage compréhensible. Par exemple, lorsqu'on parle de la capacité d'un iPod, on indique non seulement l'espace en giga-octets mais aussi en nombre de chansons.
Le prix du iPod que Michael a choisi est clairement affiché. Il en est de même des frais de livraison (c'est gratuit!). Le délai d'expédition est aussi indiqué. Pour commander, Michael n'a qu'à cliquer sur le bouton « Acheter »... ce qu'il fait sans hésitation!
Une fois la commande passée, Michael reçoit un courriel de confirmation de la part d'Apple afin de l'informer que sa commande a bien été reçue. Au moment où la commande quitte l'entrepôt, Apple informe une fois de plus Michael par courriel que son iPod est en route et qu'il peut le suivre d'étape en étape.
Quelques jours plus tard, Michael reçoit son iPod en parfait état. L'ouverture de la boîte contenant le iPod est une expérience en soi (NDLA : il y a des gens qui prennent en photo l'événement que représente le déballage de leur iPod).
La pile étant chargée et l'interface étant d'une renversante simplicité, Michael peut utiliser son iPod immédiatement. Heureux voire fier de son baladeur, il n'hésite pas à le montrer à tous ses amis.
Exemple 2 : Je veux payer un bon repas à un bon client!
Pierre désire remercier un bon client en l'emmenant manger dans un bon restaurant de Québec. Il a beaucoup entendu parler (en bien il va sans dire) du Clocher Penché et désire en faire l'expérience.
À leur arrivée, Pierre et son invité sont accueillis par du personnel attentionné et sympathique. Ils sont invités à prendre place à une table tout près d'une fenêtre. Le restaurant est éclairé et aéré (on n'y est pas cordé comme des sardines). Une musique agréable joue en sourdine, ce qui fait qu'on peut tenir une conversation sans avoir à hausser la voix.
Le menu est simple, ce qui ravit Pierre et son invité. Enfin un endroit où on n'a pas à choisir son repas dans un menu qui en comporte des dizaines, sans compter les options! Pierre choisit donc le tartare de saumon et demande à Rémi, le serveur, de lui trouver un vin qui accompagnerait adéquatement son mets. L'invité de Pierre décide lui aussi de tenter l'expérience « tartare ».
Dans les minutes qui suivent, Rémi apporte un Sémillon-Chardonnay australien qui est un pur délice. Le tartare qui suit est frais, délicat et juste assez relevé. La présentation est soignée et rend le tout fort appétissant. Chaque bouchée est un pur délice. Le service de Rémi est discret et efficace, ce qui fait que Pierre et son client ne sont pas constamment interrompus par un « Tout va à votre goût? ».
Pour terminer le tout, Pierre commande un allongé et la crème du café (crema) est parfaite. Qui plus est, le lait qui l'accompagne a été moussé à la vapeur. Tout a été fait pour que ce repas soit agréable et mémorable.
L'addition ne comporte pas d'erreur et le paiement s'effectue en quelques minutes (il n'y a rien de pire que d'attendre 15 minutes pour payer quand on a terminé un repas).
À son départ du restaurant, Pierre et son client sont salués et remerciés de leur visite par le personnel du restaurant. Satisfait de son expérience (son client a a-do-ré!), Pierre va sûrement retourner au Clocher Penché pour partager une nouvelle expérience gastronomique avec sa bien-aimée samedi prochain.
Comme on peut le constater, l'expérience utilisateur est partout. L'émotion qui en résulte est ce qui permet d'en mesurer la qualité, tout comme le degré de répétition.
Ma recommandation : connaissez votre clientèle, répondez à ses besoins (et non les vôtres!) et ayez une vue d'ensemble de l'expérience utilisateur. N'oubliez pas, le Web n'est que le commencement. Certes, il faut y porter une grande attention mais il faut aussi voir plus loin que le bout de son fureteur!
Commentaires (5) | Méthodologie
24 août 2007
Connaître avant de tester
Les essais d'utilisabilité sont là pour vérifier si l'interface permet aux utilisateurs d'atteindre leurs objectifs. Donc, pour planifier de tels essais, il faut savoir qui sont ces utilisateurs et ce qu'ils veulent lorsqu'ils visitent le site... d'où l'importance de l'enquête utilisateurs.
S'il y a une étape cruciale à tout projet de développement, c'est bien celle où on essaye de connaître l'utilisateur... et c'est malheureusement celle qui est la plus souvent escamotée! Il n'y a pas de projet trop petit pour ne pas prendre le temps de connaître l'utilisateur. Bien entendu, selon l'ampleur du projet et du budget, on prendra plus (10 à 20 j-p) ou moins (1 à 2 j-p) de temps pour connaître l'utilisateur. Quoi qu'il en soit, il faut prendre le temps. Autrement, sur quoi peut-on baser la conception d'un site? Comment peut-on préparer des essais d'utilisabilité qui en vaudront vraiment la peine?
Commentaires (1) | Méthodologie
13 février 2007
Pour des ateliers de conception vraiment productifs
Vous voulez tenir un atelier de conception pour l'élaboration d'une solution interactive et vous voulez que ça soit vraiment productif ?
Évitez de parler en l'air, écrivez et dessinez tout ce qui se dit... et pas seulement dans votre carnet de notes mais sur ce que Michael Schrage appelle un « espace partagé ». Qu'est-ce qu'un espace partagé ? C'est un tableau blanc, un poster, un napperon de restaurant, bref toute surface commune sur laquelle on exprime ce qu'on dit et ce qu'on veut vraiment dire afin de favoriser une pensée commune.
Bien entendu, limitez le nombre de participants à 3 ou 4 personnes. Il s'agit d'un atelier de conception, pas d'une présentation !
Vous voulez en savoir plus à propos des espaces partagés ? Lisez No More Teams de Michael Schrage.
Commentaires (1) | Méthodologie
17 octobre 2006
Développer plus rapidement
Plusieurs personnes se creusent les méninges afin de trouver la façon de diminuer les coûts de développement. Au début des années 90, James Martin a proposé le Rapid Application Development (dans un manuel de plus de 500 pages !). Depuis quelques années, on parle de méthodes agiles et d'extreme programming. Tout cela est certes louable. Cependant, il me semble que ça pourrait être plus simple.
Selon moi, il y a essentiellement trois raisons pour lesquelles le développement* prend plus de temps qu'il n'en faut :
1. On ne connaît pas vraiment les utilisateurs. L'étape consistant à connaître l'utilisateur est pratiquement inexistante. Ce qui fait qu'on se base sur des suppositions et des opinions pour développer, d'où ces interminables discussions qui viennent empoisonner le processus de conception. La solution : prendre le temps de connaître les utilisateurs en les observant, les interviewant, en lisant des études à leur sujet, en interviewant des tiers qui sont en contact direct avec ces derniers, etc.
2. Il n'y a pas de décideur. Lorsqu'il n'y a personne pour trancher entre différentes solutions, le risque de poursuivre ad nauseum les recherches et les discussions est très élevé. Tout le monde veut y mettre son grain de sel, tout le monde a son opinion et on n'hésite pas à consacrer beaucoup de temps afin de trouver la solution ultime. Rien de tel pour complexifier le tout... et dépasser les coûts et les échéanciers. La solution : nommer un décideur qui a un réel pouvoir de décision et qui est imputable. J'oubliais, il faut aussi que ce décideur soit disponible.
3. On ne se comprend pas. En 1994, une étude publiée dans Computerworld énonçait que la cause principale des dépassements de coûts et d'échéanciers était que les différents acteurs engagés dans un projet de développement n'arrivaient pas à se comprendre. Et ce n'est qu'à la toute fin qu'on s'apercevait que le résultat ne correspondait pas aux attentes. La solution : délaisser les formalismes traditionnels, formels et abstraits et utiliser des personnages, des scénarios, des maquettes, des cartes heuristiques, etc. pour communiquer.
Peut-être vois-je les choses trop simplement mais ce sont souvent les solutions simples qui sont garantes de succès !
* Je parle ici de développement au sens large, que ce soit de sites Web, de transactions Web ou de systèmes corporatifs.
Commentaires (2) | Méthodologie
25 février 2006
Présentation des résultats
Pour faire suite à mon précédent billet, je vous propose une façon toute simple de présenter vos résultats d'enquête utilisateur (avant même de produire les personnages).
Vous n'aurez souvent guère plus de 20 minutes pour présenter le fruit de votre enquête. Allez droit au but et limitez-vous à 10 diapositives. Évitez d'en dire trop, allez à l'essentiel ! À cet effet, je vous propose le plan de présentation suivant :
[1] : Titre de votre présentation : « Enquête utilisateur pour le projet Web-Lunch ».
[2] : Mise en contexte afin que l'auditoire sache de quel projet vous allez parler. C'est l'introduction, le « quoi ». Dans le cas qui nous concerne, cette diapositive présenterait brièvement le mandat, c'est-à -dire « Connaître comment les utilisateurs choisissent un repas pour le projet Web-Lunch qui consiste en ... ».
[3] : Le « qui », c'est-à -dire ceux qui furent l'objet de l'enquête utilisateur : le nombre d'utilisateurs (hommes/femmes), profil social, etc. Par exemple : 40 étudiants (20 hommes, 20 femmes), dont 10 étrangers et 10 sportifs.
[4] : Le(s) lieux où l'enquête a été réalisée, c'est le « où ». Par exemple : le pavillon Desjardins, le PEPS, etc.
[5] : Le « quand », c'est-à -dire les moments de la journée, de la semaine, du mois ou de l'année où l'enquête a eu lieu (si requis). Par exemple, on voudrait peut-être vérifier s'il y a des différences dans les choix alimentaires de la semaine et ceux de la fin de semaine.
[6] : La démarche employée pour connaître les utilisateurs, le « comment ». Par exemple : entrevues, observations, envoi de sondages, etc.
[7] : Ce qu'on a voulu savoir, c'est-à -dire le sujet des questions posées ou des observations effectuées. Par exemple : le prix, les allergies alimentaires, les préoccupations d'ordre religieux, etc.
[8, 9] : Présentation des résultats. Les diagrammes à barres horizontales et les pointes de tarte sont de bonnes façons d'illustrer les fruits de l'enquête utilisateur.
[10] : La conclusion mettant en évidence ce qui est ressorti de l'enquête utilisateur.
Voilà , rien de bien compliqué ! Ce faisant, vous aurez démontré que vous avez bien fait votre travail et votre client-payeur n'en sera que satisfait !
Commentaires (3) | Enquête utilisateurs + Personnages
19 février 2006
Étude de cas (1ere partie) : connaître les utilisateurs
Dans le cadre du cours « Utilisabilité multimédia » que j'enseigne au 1er cycle à l'Université Laval, j'ai donné le travail pratique suivant à mes étudiants :
Une entreprise appelée Web-Lunch veut offrir un service de livraison de repas aux étudiants et aux membres du personnel de l’Université Laval.
Le concept est le suivant : où que soit le client sur le campus, celui-ci peut commander via un site Web un repas ou un goûter de son choix et il lui sera livré dans l’heure qui suit. Ce service est disponible 7 jours sur 7, 24 heures sur 24, 365 jours par année.
Cette entreprise vous engage afin de mieux connaître les utilisateurs potentiels d’un tel service. En équipe de 5 personnes, employez une des approches présentées en classe (observation, entrevue, sondage) pour bien connaître l’utilisateur, son contexte, sa tâche et bien entendu ses objectifs. Vous pouvez utiliser plus d’une approche.
Notez que ce travail pratique servira d’intrant au prochain travail pratique qui consistera à élaborer une distribution de personnages.
À titre d'information, cet exercice suit immédiatement la matière enseignée en classe sur la connaissance de l'utilisateur. Cela dit, comment vous y prendriez-vous ?
Avant tout, il est important de bien saisir ce qu'il faut faire (!). Il ne s'agit pas de réaliser une étude de marché, mais plutôt de connaître les utilisateurs de Web-Lunch pour concevoir un site Web qui réponde à leurs objectifs. Ça semble évident, mais c'est une erreur fréquente.
Ainsi, on évitera des questions du genre :« Combien de fois mangez-vous à la cafétéria par semaine ? » ou « Commanderiez-vous votre lunch par Internet ? » ou encore « Combien seriez-vous prêt à payer pour un repas ? », questions dont les réponses ne contribueront en rien à la conception du site.
On optera plutôt pour des questions comme : « Comment choisissez-vous votre repas ? », « Avez-vous un budget concernant les repas ? », « Souffrez-vous d'une allergie alimentaire ? », « Souffrez-vous d'une maladie comme le diabète, l'hypercholestérolémie, l'hypoglycémie, etc. ? » qui pourraient se résumer par « Y a-t-il des aliments que vous ne pouvez pas manger ? », « Y a-t-il des aliments que vous devez manger ? », « Suivez-vous un régime alimentaire ? », « Si oui, pourquoi ? », « Pourquoi avez-vous choisi ce repas ? », et ainsi de suite. On pourrait même combiner certaines de ces questions pour en arriver à moins de questions. Mieux vaut quelques bonnes questions que beaucoup de questions inutiles.
Aussi, j'éviterais les questions d'âge et de sexe puisqu'on peut très aisément en déduire les réponses lors des entrevues.
Le but de cette enquête utilisateur n'est pas de savoir si les étudiants utiliseraient Web-Lunch. Le but est de savoir ce qui influence un utilisateur lorsqu'il achète un repas ou se prépare un lunch.
Maintenant que l'on sait ce qu'on veut connaître, il faut établir qui on veut observer et interviewer et où on veut le faire.
Étant donné que le concept de Web-Lunch s'adresse aux étudiants et aux professeurs d'un campus, j'aurais tendance à observer/interviewer en plus des étudiants nord-américains, des étudiants étrangers (la nourriture est on ne peut plus culturelle et parfois d'ordre religieux), d'autres qui fréquentent le PEPS (pavillon de l'Éducation physique et des sports), des étudiants qui vivent en résidence, 50 % de gars, 50 % de filles (les hommes et les femmes n'ont pas toujours le même rapport avec la nourriture), etc. Je viserais en tout une cinquantaine d'étudiants et une dizaine de membres du personnel. En complément, on pourrait aussi interviewer des préposés aux cafétérias pour en savoir plus sur ce qui, selon eux, influence le choix d'un repas.
Comme on peut le constater, le « qui » influence souvent le « où ». Ce qui fait que l'enquête devrait avoir lieu dans des cafétérias fréquentées par les clientèles identifiées.
Dans un premier temps, je procéderais par observation puis par entrevue en utilisant les questions que j'aurai élaborées.
Je vous parlerai de la façon d'interpréter les données recueillies et comment en dériver des personnages dans un prochain billet.
Commentaires (1) | Étude de cas
7 février 2006
Connaître - concevoir - évaluer ... en plus détaillé !
Voici une version détaillée du "connaître - concevoir - évaluer", l'approche de conception de sites/applications Web dont je parle dans mon livre. Cela pourrait être encore plus exhaustif mais j'ai préféré me restreindre un peu, question de ne pas vous assommer ;-).
Téléchargez la version PDF (32 Ko, 1 page) et faites en des copies pour vos amis, vos clients, vos étudiants, etc.
Commentaires (5) | Méthodologie
12 avril 2005
Un pattern... c'est quoi ça ?
À la fin des années 90, ma collègue Åsa Hedenskog et moi avons effectué des travaux de recherche sur les patterns appliqués à la conception d'interfaces utilisateurs. Pour faire une histoire courte, un pattern, c'est une solution éprouvée à un problème récurrent dans un contexte donné.
Nous avions même monté un cours (PDF : 816 Ko, 45 pages, en anglais) d'une journée sur le sujet que nous avons donné lors de conférences de la Usability Professional Association, de TORCHI et ailleurs.
Pour ceux qu'une introduction aux patterns d'interfaces utilisateurs intéresse ...
Commentaires (0) | Méthodologie
7 janvier 2005
Maudites normes !
"Maudites normes ! Ça limite totalement ma créativité !" Cette phrase, je l'ai entendue à quelques reprises au fil de ma carrière de conseiller en interfaçage et de... rédacteur de normes.
Il y a plusieurs réponses à un tel cri du coeur (!). La plus appropriée vient probablement de Jakob Nielsen (encore lui !) qui a dit grosso modo que les règles ne briment pas la créativité, loin de là . Les règles sont comme un dictionnaire et une grammaire. Elles définissent les différents objets d'interface et indiquent comment les assembler convenablement pour être compris de tous.
Je complèterais en disant que les règles préviennent aussi des incohérences dans le comportement et la présentation qui font que l'expérience utilisateur est souvent gâchée.
Commentaires (2) | Méthodologie
24 juin 2004
Pourquoi faire simple quand on peut faire compliqué ?
Les essais d'utilisabilité, notamment les séances d'essais à voix haute, ont été imaginés comme une façon économique d'évaluer une interface utilisateur. Grosso modo, on demande à de vrais utilisateurs d'utiliser une interface (papier ou électronique) pour accomplir une tâche tout en pensant à voix haute. Jusque là , rien de sorcier. Ce n'est que le gros bon sens : faire tester une interface (ou une partie de l'interface) par de vrais utilisateurs.
Cependant, juste le fait de parler d'essais d'utilisabilité provoque souvent une aura de mysticisme et de complication injustifiée. On parle d'enregistrement vidéo, de technologique, d'aménagement d'un local d'observation avec miroir sans teint, de préparation de scénarios divers, de la formation d'un animateur et j'en passe. Quoi ?
Qui plus est dans certains cas, on va même jusqu'à faire un prototype électronique fonctionnel avec les bonnes couleurs, les bonnes polices de caractères pis tout le kit. Panique ! Aurait-on perdu de vue l'objectif de ces essais ? On veut savoir si l'utilisateur comprend l'interface et s'il peut y naviguer aisément afin d'atteindre son objectif ... et ce au moindre coût. Point à la ligne.
Toute cette fausse complication a fait en sorte que les essais d'utilisabilité sont trop souvent perçus comme une étape d'assurance qualité onéreuse et non comme une activité intrinsèque à la conception. Ce qui fait qu'elle est souvent faite tardivement, trop tardivement et comble de malheur par des tiers (lire consultants). Or, pour être réellement efficaces, ces essais doivent être réalisés hâtivement, souvent et idéalement par le concepteur de la solution puisqu'il est le seul à pouvoir saisir complètement la problématique d'utilisation.
Lane Becker a d'ailleurs publié un excellent article à ce sujet. À lire !
Commentaires (0) | Méthodologie
21 juin 2004
On veut pas le saouère, on veut le ouère !
Lorsqu’on veut avoir une bonne connaissance des utilisateurs, de leur milieu, de leurs tâches et de leurs objectifs, y’a rien de tel que d’aller sur le terrain, d’aller les observer et de les interviewer en direct.
Pourquoi me direz-vous ? Eh bien, la réponse est simple. Premièrement, lorsqu’on parle directement aux vrais utilisateurs, la communication est meilleure. À l'inverse, plus il y a d'intermédiaires, plus le niveau de bruit (ajouts, omissions, transformations) augmente dans la communication.
Deuxièmement, il vaut mieux observer/interviewer l’utilisateur pendant qu’il tente d’atteindre son objectif dans son environnement que de l’interviewer dans une salle de réunion aseptisée. En effet, il existe une différence importante entre ce que l’utilisateur dit qu’il fait … et ce qu’il fait vraiment (!).
Mon ami Pierre Pilon a d’ailleurs discuté de cette problématique de communication dans un de ses premiers billets.
Le principe derrière tout ça peut se résumer en une phrase écrite par l'humoriste Yvon Deschamps : " On veut pas le saouère, on veut le ouère ! " .
Commentaires (0) | Méthodologie
10 juin 2004
D'une conception basée sur les besoins à une conception basée sur les objectifs
Lors de la conception d’un site Web, d’une application interactive ou d’un système informatique d’entreprise, il semble logique de débuter le projet par une cueillette de besoins auprès des utilisateurs.
D’ailleurs, c’est comme ça depuis des lunes en développement de systèmes. Le problème, c’est que la plupart du temps, les utilisateurs ne connaissent pas leurs besoins ou pire, ils en inventent pour prévoir au cas où. Au secours !
Par expérience, je dirais aussi que dans bien des cas, les utilisateurs sont tellement contaminés par l’existant qu’il leur est difficile de voir les choses autrement. Et quand je parle de l’existant, ça peut être une application informatique, un site Web, un formulaire papier, une brochure et même des gens qui se donnent comme mission d’être les gardiens du passé. Ce qui fait qu’ils veulent ça comme avant (!). Et c’est sans compter sur la réticence naturelle de l’humain face au changement …
Cet état de situation fait souvent dire aux concepteurs que les utilisateurs ne savent jamais ce qu’ils veulent. Et, par un raisonnement absurde, les concepteurs en viennent à se dire " Puisque les utilisateurs ne savent pas ce qu’ils veulent et que, quoi qu’on fasse, il ne seront jamais contents, on va alors leur en produire une solution … et à notre goût à part de ça ! ".
Une solution à ce problème semble être l’analyse de tâches. À la base, c’est une bonne idée. Cependant, il y a un danger à n’étudier que le comment au détriment du qui, du quoi et du pourquoi des choses. Je m’explique. Pendant des décennies, les informaticiens se sont préoccupés de mécaniser des processus, c’est-à -dire qu’ils ont observé les tâches des utilisateurs, c’est-à -dire le comment, et les ont soutenues par des systèmes informatiques. C’est bien beau tout ça mais plusieurs études ont démontré que cela n’augmente pas nécessairement la productivité ni la satisfaction des utilisateurs. Dans certains cas, c’est même l’inverse qui se produit. Aïe !
Pourquoi ? Tout simplement parce que ce n’est pas parce qu’on mécanise quelque chose que ça va aller mieux. Parfois, on croirait que les gens ne sont pas sortis de l’ère industrielle.
De fait, au lieu de porter notre attention uniquement sur les besoins ou les tâches, on devrait s’attarder aux objectifs des utilisateurs. Par exemple, si mon objectif est d’aller à Toronto le plus rapidement possible, ce n’est pas en observant comment je me déplace en voiture qu’on va trouver la solution à mon problème.
Ceci dit, je ne dis pas de ne plus étudier la tâche. Au contraire, en complément avec l’étude des utilisateurs et du contexte, la tâche permet de faire ressortir les objectifs. Il suffit simplement de changer de perspective pour orienter la conception. Il suffit de voir ça en fonction des objectifs des utilisateurs et la vie sera à la fois simplifiée pour les utilisateurs et les concepteurs.
Commentaires (0) | Méthodologie