Bruno:
Quand on est dev, on pense souvent en fonction, en architecture, en contraintes techniques. Une app doit marcher, être rapide, être sécurisé, être scalable, bref, cocher les bonnes cases techniques. Et pourtant, une application n'existe que pour résoudre un problème, et ce problème n'est pas dans votre code, mais dans la vie de quelqu'un d'autre. Mais alors, comment concevoir une app qui soit vraiment utile ? Le user est-il si différent que nous ? Et surtout, peut-on créer de la valeur sans jamais se poser la question de pour qui on code réellement ? Pour répondre à ces questions centrées, je ne reçois pas Steve Jobs, mais il s'y connaît en expérience. Raoul, bonjour.
Raul:
Bonjour Bruno.
Bruno:
Alors Raoul, est-ce que tu peux te présenter pour les quelques personnes qui ne te connaîtraient peut-être pas ?
Raul:
Donc Raoul, je suis ancien CTO, directeur d'architecture des grosses boîtes. J'ai 25 ans d'expérience et dans ma vie, j'ai fait quand même beaucoup de développement et d'applicatifs et également de l'architecture. C'est une architecture solution que l'architecture d'entreprise et de la strat.
Bruno:
Donc, on se voit aujourd'hui pour nous apprenner un peu comment rester user centrique ou user focused ou centré sur l'utilisateur final. Déjà comment est-ce que toi tu définis la notion d'expérience utilisateur c'est quoi pour toi, la quintessence du sujet ce qu'on essaie de définir aujourd'hui.
Raul:
Pour moi l'expérience utilisateur c'est qu'est-ce qu'un utilisateur va vivre au quotidien quand il ou elle va utiliser une application, donc il y a déjà de base quel est le problème qu'on est en train de résoudre ou quelle est la valeur qu'on est en train de créer ou quelle est la fonctionnalité qu'on est en train de apporter parce que parfois ce n'est pas un problème de l'utilisateur qu'on est en train de résoudre ou qu'on est en train de créer de la valeur pour l'utilisateur c'est simplement quelque chose qu'il faut faire parce que par exemple on doit répondre à un comptanteur réglementaire ou peu importe, mais l'expérience d'utilisateur c'est, Qu'est-ce que l'utilisateur vit, ressent et fait lorsque il ou elle va utiliser un applicatif, peu importe pour quelle raison.
Bruno:
Qu'est-ce qui fait d'après toi que dans certaines organisations ou certaines équipes ou certaines personnes, parfois perdre ce point d'ancrage dans leur périmètre ?
Raul:
La première raison, c'est qu'on n'y pense pas. En fait on se pose pas la question d'un point de vue projet d'un point de vue programme, de quelle sera l'expérience de l'utilisateur avec ce système que nous sommes en train de développer la deuxième c'est que parfois on y pense mais on n'a pas le budget, on n'a pas le temps, ou le budget pour ces parties là n'est pas consacré, et la troisième raison c'est que souvent les équipes en place, que ce soit les équipes de développement, les équipes d'architectes ou les programmes managers ou peu importe, pensent avoir la connaissance et la compétence sans réellement l'avoir. Parfois, on fait l'amalgame entre, par exemple, un web designer et un expert UX. Ce n'est pas parce qu'on sait faire, quelque chose de visionnement agréable qu'on va le faire efficace.
Bruno:
Oui, ce n'est pas parce qu'on sait faire un joli bouton que le bouton sera forcément cliqué.
Raul:
Exactement. Je me souviens d'une expérience là-dessus, très concrète. On recevait dans les locaux de la boîte où je travaillais à ce moment-là, le DSI et son codier d'une grosse société industrielle pour faire le tour des locaux, les présenter les différentes équipes, la Digital Factory, tout ce qui allait bien. Et donc la Digital Factory a pris l'initiative de prendre un petit morceau d'un applicatif qui est critique pour leurs opérations et de le refondre et donc leur présenter ça à ce DSI et ce Codir. Pour illustrer un petit peu les capacités et l'approche donc il y a la démo qui s'opère vraiment votre appli est magnifique ah oui mes 10 managers qui font un rapport par semaine vont être super contents, les gens qui le regardent. Par contre, mes milliers d'utilisateurs qui utilisent ça au quotidien, ça va leur faire perdre un ton monstrueux parce que quand on est dans une plante industrielle, avec un bureau qui est très resserré, qui n'a pas la place pour opérer une souris et qu'ils sont habitués à tout faire au clavier, ils font clac, clac, clac, clac, et ça y est, leur opération est finie. Là, ça prend dix fois plus de temps, c'est dix fois plus inconfortable et il n'y a personne qui va utiliser ça. Donc là, forcément, un grand moment de vide, et ça rejoint ce que tu viens on avait fait une application qui était vraiment très jolie, que pour quelqu'un qui n'a pas l'habitude de faire les opérations quotidiennes, était facile à prendre en main et qui le permettait d'effectuer certaines tâches, en compréhendant ce qu'il faisait mais pour le gros de l'utilisateur ça ne résolvait pas un problème, ça rajoutait une complexité supplémentaire et une friction supplémentaire.
Bruno:
Il y a quelques années j'étais sur une entreprise qui s'appelait auction.fr qui était un site de vente aux enchères d'objets d'art, et donc j'arrive, on devait tout refaire donc on devait faire une refonte globale du site et on m'explique que les gens qui utilisent ce site sont des gens assez old school, et qu'ils sont très nombreux en fait à imprimer les listes d'objets quand ils vont dans une vente aux enchères et donc je me dis moi je vais leur rendre service je vais rendre service à mes utilisateurs et donc j'ai passé un temps quand même assez conséquent à créer toute une feuille CSS pour que quand t'imprimes la page d'un objet ça s'imprime proprement sur une feuille A4 et que ce soit joli et confortable à utiliser donc j'étais quand même hyper fier de moi on pousse le truc en prod et mais vraiment quelques heures après je crois le lendemain de cette mise en prod on débarque dans le bureau et on me dit Bruno on a un problème on peut plus imprimer, Alors, je ne comprends pas, j'ouvre la page, je fais mon pumpé, et la page s'imprime, on me dit, mais comment tu as fait ? Je dis, ben, j'ai appuyé sur pumpé. Et en fait, c'est que, le truc que je n'avais pas pensé, c'est que, certes, j'avais fait une impression qui était jolie, mais j'avais retiré le bouton imprimé sur la page en me disant, les gens, ils savent faire fichier imprimé, ou contrôle P, ou pumpé. Mais en fait, non, comme les gens sont effectivement des gens old school, ils ont besoin de voir le bouton imprimé pour savoir imprimer. Donc, comme ils ne voyaient plus le bouton, pour eux, c'était plus possible d'imprimer. Et donc, j'avais fait beaucoup de travail en me disant, je vais répondre aux problèmes et puis en fait, j'en ai créé un nouveau.
Raul:
Ça, justement, c'est quelque chose de très intéressant et qu'on a tendance à faire, moi le premier. C'est qu'en tant que développeur, on connaît notre application. Donc, on sait comment elle fonctionne, on sait comment on l'opère, on connaît les raccourcis qu'un ami, on sait comment, nous, on a cherché à se simplifier la vie et à être le plus efficace possible. Sauf qu'un utilisateur lambda, n'a pas cette connaissance de l'application. Donc un utilisateur lambda n'aura pas forcément, le réflexe de faire pomper ou ctrl-p pour imprimer une page, ou même il peut faire un peu d'overthinking là-dessus, et dire non mais le ctrl-p c'est du système alors que là je suis dans une page web, si jamais je le clique, je fais pomper ça risque d'imprimer n'importe quoi. Donc on réfléchit à notre expérience en tant qu'utilisateur qui connaît l'application et on ne réfléchit pas au point de vue de quelqu'un qui n'est pas dans notre tête comme je le disais tout à l'heure c'est très facile d'être d'accord avec soi-même, donc là-dessus une bonne une bonne, une bonne pratique, quand on a ce genre d'idée ou d'initiative, c'est de la confronter avec des personnes qui représentent les utilisateurs lambda, voire de la prototyper et leur demander de tester. Si je reviens un peu au monde du jeu vidéo, il y a toute une branche dans le développement et dans l'édition des jeux vidéo, qui s'appelle les user tests ou les play tests ou les game tests, dans lesquels on demande à des joueurs, qui ont été choisis, qui représentent différentes populations de joueurs, ça peut être des hardcore gamers, des joueurs lambda, des joueurs occasionnels, des différents groupes d'âge, etc., de prendre le jeu et de jouer. On va les filmer pour voir leurs réactions, pour voir où est-ce qu'ils ont des frustrations, est-ce que ça permet aussi d'équilibrer le jeu ou est-ce qu'il est trop facile, pas assez facile, est-ce qu'ils arrivent à comprendre le mécanisme pour progresser. Donc, volontairement, on va tester ce qu'on a développé pour voir comment différents types de populations vont réagir, face à cette implémentation donc même quand on est sur quelque chose de beaucoup plus basique comme implémenter une fonction d'impression sur un site web, on peut prendre un petit peu de temps pour confronter cette idée avec des utilisateurs qui ne sont pas dans notre tête et qui forcément vont poser des questions sur les problématiques que nous on ne voit pas parce qu'on a fait un raccourci, ça fait partie des biais cognitifs. En fait, notre cerveau est très très fort pour faire des raccourcis.
Bruno:
Tu disais tout à l'heure que une des raisons pour lesquelles parfois on s'éloigne de ces sujets-là, c'est que les organisations ou les budgets ne sont pas forcément alignés avec ces trucs-là, ou qu'on n'y pense pas, on l'oublie. Malgré tout, on voit qu'il y a quand même beaucoup d'équipes dans lesquelles on a une ou plusieurs personnes qui sont là pour faire de l'UX, donc de la user experience, qui pourtant sont là pour justement porter ce message-là. Est-ce que pour toi-même, quand on a une personne UX, ça ne suffit pas, ou est-ce qu'il y a un ratio nécessaires à avoir entre UX et Dev. Comment est-ce que tu vois la présence de ces équipes ?
Raul:
Pour tout te dire, en 25 ans de carrière, j'ai fait un seul projet dans lequel il y avait une équipe UX dédiée. Dans tous les autres projets, ça n'avait pas été pris en compte, ça n'existait pas, ou ça avait été demandé, mais pas le budget, ou peu importe. Donc, de mon expérience, la seule fois où il y avait une équipe UX de ce côté là le projet avait été réussi, dans les autres cas c'était plus ou moins aléatoire en fonction de la complexité de l'application d'à quel point on reproduisait des choses déjà existantes et qu'on rentrait dans les habitudes des utilisateurs, mais je ne pourrais pas te dire des choses plus représentatives que ça j'entends.
Bruno:
J'imagine que tu as quand même connu peut-être plus de projets, où tu avais un PO ou un PM qui était là quelque part sur le projet. Aussi, normalement, ils portent cette vision produit, cette vision un petit peu utilisateur.
Raul:
Hum... Dans mon expérience, les PO ou PM, quand j'étais vraiment dans des organisations agiles avec une vraie approche produit, alors ce n'était pas nécessairement des produits portés vers l'extérieur. Donc typiquement, la notion de friction ou d'adoption d'une application n'était pas nécessairement prise en compte, n'était pas importante, parce que de toute façon les utilisateurs doivent l'utiliser, ils n'ont pas le choix. Mais les PM étaient beaucoup plus portés sur le métier que sur l'usabilité de l'application donc à moins qu'il y ait des gros problèmes, ces problématiques-là n'étaient pas vraiment traitées C'est.
Bruno:
Intéressant cette distinction métier et usabilité c'est-à-dire que moi j'aurais tendance à les considérer ensemble, c'est-à-dire que, la manière dont le produit est utilisé est aussi importante que le produit enfin que le résultat que produit une solution technique ?
Raul:
Alors dans ce cas par exemple il y avait des problématiques importantes autour d'aspects réglementaires par exemple donc ça s'apprimait surtout parce qu'il fallait être conforme aux réglementations, ensuite on était sur des métiers qui évoluaient relativement vite avec des contextes extérieurs aussi qui changeaient fréquemment. Donc la principale problématique, c'était les fonctionnalités elles-mêmes et la conformité réglementaire et beaucoup moins sur les aspects purement UX et UI du produit.
Bruno:
Du coup, quand on est dans une équipe où effectivement il n'y a pas de gens côté UX ou des gens côté produit qui s'intéressent plus côté métier qu'au côté usabilité, comment est-ce qu'on peut faire en tant que développeur ou développeuse pour justement porter cette parole de l'usabilité, de l'utilisateur, pour pouvoir prendre en compte ces sujets-là au moment de la conception ?
Raul:
La première chose, c'est d'être conscient. La deuxième chose, c'est d'être conscient que nous avons tous des limitations, que nous avons un domaine d'expertise et des domaines sur lesquels nous n'avons pas d'expertise. Et du coup, l'accepter et utiliser ça pour se poser les bonnes questions. Même aujourd'hui, avec la GNI, on peut parfaitement prendre l'outil GNI de notre choix et lui poser la question. Et lui dire, je suis développeur, je suis en train de mettre en place une application de telle chose, telle chose. Quelle considération d'un point de vue UX, je dois prendre en compte ? Ou quelles questions je dois me poser avant de commencer à concevoir une page ou concevoir une application mobile ? Je dois me poser pour être représentatif d'un utilisateur. Ou voir, tu es un expert UX, UI, je suis en train de développer telle application. Challenge-moi et pose-moi les questions qui peuvent avoir un impact sur la UX des utilisateurs. Donc aujourd'hui, c'est facile, même sans avoir l'expertise et l'expérience, comme je le disais tout à l'heure, il n'y a pas d'algorithme de compression pour l'expérience. Donc le savoir-faire d'un expert UX qui fait ce métier depuis un certain temps qu'on a vu des vertes et des pas mûres, donc cette expérience sera irremplaçable. Mais quand même, si on ne l'a pas, parce que c'est une contrainte, ce n'est pas un choix, on a quand même le droit de se poser des questions et d'utiliser tous les outils dont nous disposons aujourd'hui pour aussi sortir un petit peu de notre zone de confort et pour regarder les choses d'un prisme différent.
Bruno:
Mais l'usage d'un chat GPT ou autre IA génératif pour se donner des idées il y a comme un, risque, le mot peut-être un petit peu fort mais les suggestions ou les améliorations, les axes d'attention, proposés par un outil comme un chat GPT vont être quand même très génériques et pas forcément adaptés à un contexte un peu spécifique tu vois, tu as évoqué un cas, où il y a beaucoup de sujets de réglementation ou ce genre de choses ne sera pas forcément adapté à n'importe quel... Il peut y avoir des contextes un peu spécifiques. Il faut que les conseils proposés par le HDPT sont trop génériques, sont trop vagues, trop flous.
Raul:
Oui, jusqu'à un certain point. Après, en faisant correctement du prompt engineering, on peut arriver à avoir des résultats beaucoup plus spécifiques et beaucoup plus pertinents que simplement avec une question bateau. Aujourd'hui avec les outils de deep research, on peut arriver à faire déjà des rapports et des compilés qui sont très pertinents sur un thème donné et ensuite on peut combiner ces éléments avec d'autres pour affiner et avoir des réponses pertinentes évidemment une GNI ça reste une GNI donc il ne faut surtout pas prendre ce qui soit d'une GNI comme de la Bible, il faut toujours avoir un regard critique. Et également avoir en tête qu'est-ce que je suis en train de lui demander, quel est le problème que je cherche à résoudre en posant une question à la GNI. Donc dans ce cas, par exemple, ça peut être un challenge moins. Donc forcément, il va poser des questions. Ces questions globalement vont être pertinentes. Elles ne couvriront pas l'exhaustivité, mais ça sera probablement mieux que si on avait en fait. Encore une fois, une GNI ne remplacera pas l'expertise d'un expert UUX. Donc si on a l'opportunité de l'avoir, déjà si avant de commencer le programme, on se dit, c'est quoi notre budget UUX ? On démarre d'un bon pied. Si on arrive dans un projet qui est déjà lancé, peu importe, que l'organisation ne l'a pas, que le budget n'est pas là, que ça n'a pas été pensé, et tant pis, on fait avec ce qu'on a. Mais déjà, rien que le fait de se poser la question de se mettre dans les chaussures de l'utilisateur et de regarder les choses depuis un prisme différent peut faire une différence énorme à l'arrivée.
Bruno:
Mais effectivement, comme tu le dis, c'est un métier à part entière.
Raul:
C'est un métier à part entière. Comme un métier de développeur. Quand on dit, je prends un chat GPT et je demande de développer un truc... Oui, il va faire des choses techniquement correctes, pas toujours. Ça peut remplacer un développeur junior, ça ne peut pas remplacer un distingué d'ingénieur de chez Google. Forcément, il y a un gap. Donc, c'est des outils. On a le droit de les utiliser. Il faut quand même comprendre leurs limitations et avoir ce regard critique et ne pas prendre le résultat dans le chat GPT comme étant la sainte parole et la Bible.
Bruno:
Parce qu'on voit effectivement des équipes dans les entreprises où effectivement, comme tu le dis, les moyens sont parfois limités, où on demande à un développeur ou une développeuse d'assumer le rôle de PO ou de PM et autres. Donc effectivement, on peut demander à un autre de s'occuper de cette vision user. Comment faire pour, ne pas perdre de vue justement cette approche client parce que, la difficulté c'est que justement on est dans une démarche de résolution de problème et en fait on peut perdre de vue, tu vois comme moi je l'ai pu faire avec ce fameux bouton imprimé on peut au bout d'un moment perdre de vue, la connaissance du client en tant que tel, comment tu fais pour insuffler une dynamique permanente de prise en compte de l'utilisateur final ?
Raul:
Alors j'avoue que c'est tellement automatique qu'ils ont gravé dans ma tête que j'ai un peu de mal à le rationaliser. Alors déjà dans le rituel. Donc quand on fait par exemple un sprint review, se poser la question, quand on fait du LUT, prévoir des tests d'usabilité. Donc ne pas simplement se concentrer sur les tests fonctionnels. Faire de la recherche aussi, donc garder son esprit un peu. Je veux paraphraser Jean-Claude Vendamme aware que cette problématique existe. Donc au même temps au même titre qu'on va faire de la recherche sur la technologie, quand on va faire de la lecture sur la technologie c'est de s'intéresser à ce sujet là, donc c'est une personne, aussi dessiner une personne dans l'équipe qui sera entre guillemets responsable de porter ses volets, ça ne veut pas dire que cette personne soit responsable de tout faire, ça sera un peu le champion de l'UX et de l'UI au sein de l'équipe et c'est lui qui vendra enquiquiner les autres, n'oublie pas de penser à l'utilisateur donc forcément on ne fait pas ça tous les jours, tout le temps parce que développe plutôt des fonctions back-end, ça va être différent mais dès qu'on touche à l'interface utilisateur donc systématiquement d'avoir quelqu'un dans l'équipe qui va attention, t'y as pensé, et après comme je l'ai dit tout à l'heure je me répète peut-être mais c'est très facile de être d'accord avec soi-même donc, prévoir des phases de test d'usabilité de l'application par des personnes qui ne sont pas développeurs, qui ne sont pas au courant de tout ce qu'on fait et qui représentent différentes populations. Parce que si, ce n'est pas simplement parce qu'on a rendu quelque chose de trop facile que c'est un bon UX. Parce que parfois, on peut aussi avoir des experts qui ont besoin de faire des choses plus complexes et si on leur masque ces fonctionnalités-là, ça engendre aussi de la frustration. Par exemple en tout complètement perso, côté utilisateur avec ma compagne, nous avons installé ou fait installer plutôt un système de domotique, et donc il y a une application de domotique et ensuite il y a un logiciel, plutôt hardcore pour aller rentrer vraiment dedans pour paramétrer finement chacun des éléments de cette domotique donc je prends l'application je commence à vouloir définir de règles. Déjà, j'étais en train de m'arracher les cheveux parce que ça ressemble à un moteur de règles conventionnel mais ça ne fonctionne pas du tout comme un moteur de règles conventionnel. Donc, il y a de fortes chances que cette équipe de développement ait réinventé la roue au moment d'implémenter ce moteur de règles. Donc, en tant d'expérience utilisateur, quand on est expert et qu'on connaît un moteur de règles et que la documentation n'est pas hyper exhaustive là-dessus, et qu'on veut mettre en place une règle qui fonctionne sur Drools, par exemple, peu importe, et qu'elle ne fonctionne pas, c'est extrêmement frustrant. Ou quand on a envie ou besoin d'accéder à des paramètres un peu plus poussés. Comme par exemple. Quelque chose de parfois très simple. Combien de temps met une lumière à s'éteindre à partir du moment où elle ne détecte plus une présence dans la pièce. C'est la croix et la manière pour aller paramétrer ça, parce que ce n'est pas possible de le faire depuis l'application. Donc, il faut rentrer dans le logiciel expert, qui ressemble presque à un AutoCAD, pour ensuite aller identifier l'ID de l'élément qu'on cherche à paramétrer, ensuite rentrer dans 17 menus différents, pour finalement trouver le nombre de millisecondes, que cet élément-là va prendre pour étendre la lumière, à partir du moment où, la personne est plus détectée dans la pièce.
Bruno:
Mais tu vois, cette complexité, est-ce que c'est pas aussi un moyen de, en fait, cacher la version hardcore, on va dire, en tout cas pour les visiteurs experts, parce qu'en fait, la population cible, justement, c'est pas les gens experts, c'est plutôt des gens qui ne maîtrisent pas tous ces sujets-là, et qui préfèrent avoir au final trois boutons à appuyer pour que ça fonctionne ou pas, et que en cachant tout ça, ça rend le truc plus compliqué pour des experts, mais ça rend le truc beaucoup plus facile pour des non-experts.
Raul:
Complètement. Par contre, ce que je veux dire, c'est que l'interface expert, il y a absolument zéro recherche en termes de UIX. C'est juste un amas de menus et d'éléments avec pratiquement zéro documentation. Donc ça a été conçu par les développeurs de ce système de domotique pour les développeurs de ce système de domotique. Donc quelqu'un qui est installateur, même j'ai discuté avec l'installateur qui m'a dit, nous aussi on se prend énormément la tête parce que le, workbench expert est très complexe à utiliser parce que les éléments sont, tout est codé, tout est caché. Donc si on ne maîtrise pas parfaitement presque que l'électronique de ce système-là, c'est très difficile à comprendre la paramétrie. Après, il y a des choses, par exemple, c'est des choses qu'on ne va pas modifier tous les jours ou toutes les cinq minutes, mais je ne devrais pas non plus être ingénieur électronique polytechnicien pour pouvoir changer combien de temps met une lumière à s'éteindre, après la détection ou la fin de la détection de la présence.
Bruno:
En effet, j'entends. donc ce que tu nous expliques c'est que tu essaies de faire en sorte de désigner quelqu'un qui est responsable de chez Sojak des sujets d'utilisation d'usabilité, que dans les différents rituels qu'on a dans l'agile t'essaies d'inclure ces sujets là, est-ce que tu ajoutes aussi des, rituels pour faire en sorte que l'ensemble des développeurs et développeuses aient aussi cette connaissance de l'utilisateur ?
Raul:
Peut-être pas forcément des rituels, mais plutôt des moments de partage, type Brambag lunch ou autre, dans lesquels on va aborder cette problématique de lui-x-lui. Mais de façon moins systématique. Si j'arrive dans une nouvelle équipe, après faire un petit sondage interne, voir quel est le niveau de sensibilité des différentes personnes, voir si c'est nécessaire d'introduire quelque chose d'un peu plus fort. Sinon, en général, ça va être plutôt pendant la mise en œuvre qu'on va ajuster le tir et commencer à prendre en compte ces problématiques-là.
Bruno:
Tu parlais du fait que tu as vu assez peu de projets où il y avait quelqu'un d'UX, un expert UX qui était vraiment là pour apporter ça. Moi, ce que j'ai pu voir, c'est aussi des projets ou des équipes où il y a justement des gens qui sont sur la partie UX et où du coup, les équipes se reposent intégralement dessus. Et où donc en fait le reste des équipes n'ont absolument aucune connaissance des utilisateurs parce qu'on se dit c'est les UX qui le font donc quand l'UX me dit de faire un truc, je fais comme ça et puis c'est marre, est-ce qu'il n'y a pas quand même enfin tu vois, parce qu'on parle effectivement de comment faire pour garder cette attention sur l'usabilité des produits, mais je pense que ça passe aussi par une étape primordiale qui pour moi doit être partagée par tous, pas que par les UX c'est de connaître en fait les utilisateurs c'est pas uniquement de se dire est-ce que je réponds bien à leurs problèmes mais c'est de connaître leurs problèmes, de connaître ces gens-là de connaître un peu les personas de s'y frotter au final d'une certaine façon.
Raul:
Oui, complètement. Surtout quand on est loin de la problématique qu'on cherche à résoudre. Quand on va développer une application, peu importe quel type, pour un métier ou pour un utilisateur ou pour adresser une problématique qu'on n'a jamais vécue nous-mêmes, c'est très facile de complètement négliger cette partie-là et de partir juste sur le standard ou sur les autres. Après, j'ai envie de dire, ça dépend un peu de la curiosité et de l'esprit de chacun. Il y en a qui, systématiquement, vont se poser la question de pourquoi je fais ça, pourquoi on me demande de faire ça, et comment je peux faire différemment. Et il y en a d'autres qui préfèrent se concentrer à comment je fais pour mieux coder cet élément. Et l'UX, ce n'est pas mon problème. J'ai un UX qui me dit de faire ça. Je ne vais pas le remettre en question son travail, de la même façon que l'UX ne remet pas en question mon travail de développeur. Mais je pense que ça, c'est beaucoup plus personnel.
Bruno:
Moi, tu vois, j'essaye de développer cette culture de la connaissance client. En général, dans toutes les équipes de dev dans lesquelles je suis amené à passer. Et jamais, tu vois, amener les gens à faire du support client. Tu vois, en tout cas, écouter des appels téléphoniques ou de prendre des e-mails. De participer à ces moments-là qui sont au final les rares cas où l'entreprise est en contact direct avec un utilisateur pour justement avoir cette connaissance des gens. Parce que je pense que quand tu connais les gens, tu prends plus facilement en compte leurs problématiques et leurs sujets.
Raul:
Là, je suis complètement aligné. Je suis convaincu que le vie ma vie ça permet à n'importe qui, pas forcément un développeur, mais de comprendre la problématique de l'autre, de développer une forme d'empathie et également de, trouver des solutions à des problèmes qu'autrement on ne verrait jamais. Dans ma vie chez Amazon, l'une des caractéristiques c'est que Jeff Bezos, même jusqu'à la fin de sa carrière, régulièrement il allait faire vivre ma vie à différents endroits de l'entreprise. Donc il y a une des anecdotes où il était en train de faire la vie ma vie du service client donc il était en shadow à côté d'une personne lambda du service client donc il y a un client capé oui bonjour, donc il y a la commande qui apparaît sur le système donc le, le représentant de service client qui coupe son micro il dit tu vas voir il a un problème avec cette table qu'il vient d'acheter et il est rayé sur le côté, il y a Jeff qui dit rien il regarde effectivement c'était ce problème là. Donc le client qui se plaignait que la table était arrivée rayée sur le côté c'était le bon article le bon problème donc la personne de service client n'a pas de problème vous envoyez le bon pour la renvoyer etc le traitement classique du service client Amazon, quand la conversation est finie, donc Jeff qui les demande comment tu savais, que cette personne avait ce problème avec ce produit, parce que il y a un défaut dans l'emballage, donc, 6 fois sur 10 on a des clients qui nous appellent pour ce même problème donc on est déjà tellement rodé on a tellement vu des fois les 3 dernières semaines, que maintenant dès qu'on voit ce produit apparaître on sait déjà quel est le problème on sait comment le résoudre, mais tu as remonté l'information Oui, on a remonté l'information à l'équipe produit, ils ont dit qu'ils allaient la traiter. Mais ça s'est arrêté là, on ne sait pas ce qui s'est passé. Il a commencé à creuser, effectivement, l'information a été remontée, ça suivait un process. Il y avait une enquête en cours avec les fournisseurs. Mais ça ne résolvait pas le problème de la personne qui commande un produit et qui le réservait abîmée. Donc Jeff s'est inspiré de Toyota. Toyota a un mécanisme qui s'appelle le hand-on-corde. C'est littéralement une corde qui suit toute la chaîne de production. Quand un employé voit qu'il y a un défaut dans la chaîne de fabrication, tire la corde et arrête toute la chaîne de production de Toyota. Pourquoi ? Parce que Toyota considère que c'est moins cher et plus efficace de résoudre un problème à la source, plutôt que laisser un produit défectueux sortir de l'usine et devoir le gérer plus tard. Donc n'importe quel employé a le pouvoir d'arrêter la chaîne de production s'il détecte un défaut de fabrication, donc ce qu'a fait ce qu'a demandé Jeff Bezos à sa équipe c'était d'introduire un bouton pour les services clients, quand il y a un problème qui se reproduit ils ont la capacité de sortir immédiatement un produit du stock donc si les services clients détectent qu'un produit a un défaut d'emballage ou de fabrication peu importe, qu'il y a des problèmes récurrents il s'appuie sur ce bouton-là et le produit est immédiatement sorti du site, il n'est plus vendu. Donc ça revient à ce qu'on disait tout à l'heure, c'est la personne qui est la plus proche du problème peut prendre la bonne décision à partir du moment où il a les bons éléments. Et deuxièmement, c'est en étant au contact direct de la situation, qu'on va comprendre vraiment les problématiques du quotidien et non pas depuis un tour d'ivoire ou depuis un centre de développement qui est très loin du métier. Donc pour moi, le vie ma vie, ça permet toujours d'avoir un regard différent sur les choses et du coup, commencer à se poser des questions différentes.
Bruno:
Oui, effectivement. Alors, ce qui est intéressant, c'est qu'effectivement, Jeff, Il apporte en fait une solution, c'est-à-dire que lui, son utilisateur, c'est ses employés. Et donc, effectivement, il apporte une solution à ses employés pour résoudre le problème. Mais au final, il permet aussi à ses employés d'apporter une solution à l'utilisateur final, indirectement. Parce que du coup, les gens arrêtent d'acheter une table qui est rayée sur le côté.
Raul:
En fait, lui, d'abord, il se met à la place du client. Donc, comment se sent un client quand il achète un produit et qu'il le reçoit dans cet état-là ? Donc déjà, la première chose, c'est comment je fais pour enlever la frustration du client Donc là, sur le long terme, c'est résoudre le problème d'emballage, et s'assurer que le produit est reçu dans les bonnes conditions. Immédiatement, la seule façon que l'utilisateur ou que le client ne soit pas frustré, c'est qu'il ne puisse pas l'acheter. Parce qu'on sait déjà qu'il y aura forcément un problème. Donc c'est d'abord comment je résoudre le problème du client. Et donc dans ce cas, c'est éviter qu'il puisse acheter un produit défectueux, qu'on sait qu'il est défectueux. Et ensuite, c'est comment je facilite la vie de mon service client. Aussi parce que, pour Amazon, d'un point de vue économique, ça tient la route. C'est coûteux de traiter tous ces retours. En fait, le fait d'expédier un produit à un coût, le fait de le retourner et le traiter l'entrepôt à un coût, le temps de la personne de service client à un coût, et même si ce sont des coûts qui ne peuvent pas être négligeables individuels, à l'échelle d'Amazon, c'est des montants de faramilien. Donc il y a aussi cet élément économique qui rentre dans l'équation.
Bruno:
Alors justement, tu parles d'éléments économiques. Comment faire pour concilier, j'essaie de former ma question en même temps, mais concilier on va dire la valeur qu'on crée en tant qu'entreprise et l'usabilité. Qu'il y ait des possibilités qui peuvent se présenter ou en fait en voulant faciliter la vie de l'utilisateur, tu peux en fait t'éloigner du service d'origine, que t'essayais de produire. Je prends un exemple, t'as peut-être déjà vu parce que ça avait beaucoup buzzé à l'époque, c'était quoi ? Comment s'appelait cette boutique de chaussures Zappos ? Il y avait un truc de vendeur de chaussures où le gars expliquait qu'il mettait la satisfaction client au centre de tout et qu'en fait tu pouvais appeler le service client de cette marque-là, il me semble que c'était Zappos, je ne suis pas sûr du nom, et que tu pouvais leur demander à ce qu'ils te commandent une pizza. Et ils te commandaient une pizza, en fait, parce qu'ils étaient là pour venir, au service de l'utilisateur, quitte à ce que ce ne soit pas du tout une demande en lien avec le service d'origine du produit. Tu vois ce que je veux dire ? Tu peux avoir une espèce de, à être trop user-centric, te décaler de la valeur que tu essaies de produire en tant qu'entreprise ?
Raul:
Là, je pense qu'on rentre un peu dans des dérives. C'est peut-être une dérive qui a été acceptée pour faire du buzz. Je ne connais pas le cas précis. Je ne vois pas quelle est la valeur que les chaussures créent pour un utilisateur en lui commandant un pizza ou quels sont problèmes qu'ils résoudrent alors qu'il y a Uber Eats, par exemple, qui peut faire la même chose et qui a un service dédié et qui sera plus efficace. Là pour moi c'est vraiment une dérive et c'est quelque chose de complètement exagéré par rapport à la vraie question qui est comment je m'assure, que l'application ou le service que je développe crée effectivement de la valeur pour l'utilisateur là ce n'est plus créer de la valeur c'est juste la rigolade mais, ça a peut-être été fait exprès mais je ne connais pas le cas.
Bruno:
Mais tu vois, si on reprend l'exemple de Uber, dont l'affinité en tant qu'entreprise est de permettre à des gens de se rendre d'un point A à un point B, en gros, il y a tout un ensemble de mobilités possibles et imaginables. Je ne sais pas, admettons que à force de vouloir rendre la vie facile à leurs clients, ils se retrouvent à proposer de quasiment avoir un service bancaire où tu peux, payer ton bus, ton ticket RATP avec ton application Uber Eats. Il y a quand même un moment où tu t'écartes un peu de ton but premier.
Raul:
Déjà, Uber, à la base, sa mission, c'était pas de permettre aux gens de se rendre dans un point A à un point B. C'était de permettre à des personnes de proposer des services à d'autres personnes via une plateforme qui était plus ou moins cadrée, avec un minimum de sécurisation dans cet échange-là. La première implémentation de ça, c'était la voiture. Mais c'est un peu le... Quand on revient à Amazon, on dit Amazon, c'est un retailer qui fait la tech. Non, Amazon, ce n'est pas un retailer qui fait la tech, c'est une boîte de tech qui fait le retail. Et toute l'évolution et le développement d'Amazon vient du fait que leur mission, c'était de faire de la tech. Le retail, c'était un des moyens ou une des applications de la tech. Mais leur ADN et leur mission, c'est la tech. Donc dans le cas d'Uber, leur mission, ce n'était pas la voiture, c'était permettre à des particuliers d'offrir des services à d'autres particuliers en ayant une plateforme sur laquelle l'échange pouvait se faire de façon plus ou moins cadrée, plus ou moins sécurisée. Et il y a eu énormément d'évolutions justement, en particulier autour de la sécurisation de ces prestations de services. Donc il y avait la voiture, il y avait Uber Eats. c'est des particuliers qui font la qui réalisent la livraison et donc c'est des commerces qui proposent des services à des particuliers qu'autrement n'auraient pas accès parce que ces commerces là n'ont pas la possibilité d'avoir des services de livraison qui leur sont propres.
Bruno:
Donc tu vois pas de cas où à force de se concentrer sur la facilité ou l'usabilité d'un produit on peut petit à petit s'écarter de la valeur qu'on essaie de produire en tant qu'entreprise.
Raul:
Si, on peut. Mais je pense que ça arrive quand la vision ou la mission de l'entreprise n'est pas claire. Ou alors quand on autorise ou s'autorise à faire des choses qui ne sont pas alignées avec cette mission et cette vision. Ce qui ne veut pas dire que le monde évolue, le marché évolue et que ce qui est vrai aujourd'hui ne sera pas vraie de monde où ce qu'il va aujourd'hui peut changer demain. Donc on peut s'autoriser ce changement et aller vers d'autres choses et d'autres marchés, d'autres modèles économiques, pourquoi pas. Mais à ce moment-là, c'est à cette dérive qu'on constate. Est-ce qu'on ne doit pas se poser la question de quelle est notre mission et notre vision ?
Bruno:
J'entends. Est-ce que du coup, tu fais partie des fans du DDD, le domaine du design ?
Raul:
Complètement. J'adore le DDD justement parce que ça, Ça nécessite de rentrer dans le fonctionnel, dans le métier pour se poser les bonnes questions pour ensuite, à partir de là, tirer l'organisation de l'application. Je trouve que ça a pris quand même beaucoup d'essor avec l'arrivée des microservices. Je pense que faire des microservices sans faire du DDD c'est presque se tirer mal dans le pied. Après, je ne suis pas un taliban de la méthode, mais, Le DDD apporte énormément dans ce cadre-là. Justement, quand on fait des microservices, la première question qu'on se pose, c'est quelle est la granularité. Soit s'ils sont trop gros, on rentre dans l'ISO à la papa et là, on perd énormément d'avantages des microservices. Et s'ils sont trop fins, en fait, ce n'est plus des microservices, c'est juste un amas des méthodes et des fonctionnalités qui se baladent, mais qui sont incontrôlables, ingouvernables. Donc le DDD apporte une certaine cohérence à ce niveau là même s'il existe depuis bien avant qu'on invente le concept de microservices.
Bruno:
Je suis un grand fan aussi du DDD et ce que je trouve en plus intéressant avec le DDD c'est que même en termes de d'onboarding pour les nouvelles recrues, c'est que, même en lisant la code base les développeurs et les développeuses apprennent des choses sur le métier parce que c'est tellement ancré dans le code qu'en lisant le code, on comprend comment est-ce que le métier ou le service qu'on essaie de résoudre est organisé.
Raul:
Je suis complètement d'accord là-dessus. Je suis convaincu. Surtout, ça permet d'avoir une approche aussi plus top-down. En tant que développeur, pareil, on a tendance à plonger dans le code. On aime le code. Et parfois devoir interpréter qu'est-ce qui a été codé, de quelle façon on peut arriver à comprendre qu'est-ce que ce code fait, C'est beaucoup plus difficile que comprendre qu'est-ce qu'on est en train de faire d'un point de vue métier et à partir de là, pouvoir analyser de quelle façon ça a été fait, pourquoi et de quelle façon je devrais potentiellement le faire évoluer dans le futur. Et quelque chose qui est intéressant aussi avec le DDD et les services qui suivent ça c'est qu'avec les Génia et les agents quand on a des services ou des applicatifs qui exportent des API proches des domaines DDD ça facilite énormément les agents autonomes qui sont capables de générer du code pour orchestrer des tâches parce que typiquement copilote sur Power Apps, il est capable de se connecter sur une API, d'inférer ce que cette API fait et ensuite d'écrire et d'orchestrer le code nécessaire pour effectuer une tâche que l'utilisateur a demandé à partir de ces APIs qu'on appelle. Donc quand on a un code qui est bien organisé, ça peut avoir aussi un impact positif, il fait une différence énorme dans la vague de l'IA qui vient qui est l'IA gentil ?
Bruno:
Tu parlais sur le compilé du billet des coûts irrécupérables. Là, ça, c'est une vérité dans le monde dans lequel on est aujourd'hui, parce que nos LLM sont entraînés, c'est des modèles de langage, et donc ils sont capables d'inférer ces éléments-là grâce au langage qui est présent dans le code. Mais si on imagine demain des IA qui sont entraînés uniquement sur du code, ou sur une autre compréhension du monde, on va dire, ou interprétation du monde, ils ne seront peut-être pas aussi performants grâce au DDD ? Tu vois ce que je veux dire ?
Raul:
Je vois ce que tu veux dire. Je ne sais pas si ça sera un vrai problème, parce qu'à moins d'être dans la recherche de l'hyperefficacité, je pense qu'on aura tendance plutôt à utiliser des modèles multimodales qu'à l'essent des modèles ultra spécialisés sur un élément spécifique. Je pense qu'en particulier dans le cas des agents, et le fait de pouvoir automatiser des tâches complexes qui nécessitent un semblant de raisonnement à partir d'un prompt, forcément, on a besoin d'avoir des modèles de langage. Et là, ça va venir apporter. Encore une fois, si on va rentrer dans des modèles très spécifiques sur des tâches différentes, là, ça va être plutôt des agents qui sont construits de façon beaucoup plus structurée et qui vont répondre à des besoins très spécifiques. Mais j'ai pas la boule de cristal donc je sais pas te dire si c'est un problème.
Bruno:
Qu'on va avoir ou pas Pour terminer j'aurais une dernière question donc toi qui as connu des projets sans personne dédiée à l'UX et avec des personnes dédiées à l'UX, est-ce que tu penses que cette notion de, après tu me dis être fan du DDD donc j'ai peut-être déjà un peu la réponse mais est-ce que tu penses que c'est sujet d'usabilité de focus sur l'utilisateur, est-ce que c'est un sujet qui doit être porté par tout le monde, mais du coup avec une responsabilité un peu diluée ou est-ce qu'il vaut mieux avoir des personnes dédiées à ça quitte à ce que les autres qui ne sont pas, se désengagent de ces sujets-là, t'as pas le droit de me dire un peu des deux.
Raul:
Je pense que ce n'est pas parce que il y a une personne, une équipe qui est dédiée en fonction que les autres doivent se désintéresser de cela. Euh... Donc, je pense aussi que tout le monde est responsable de faire le mieux possible pour l'utilisateur, pour le client, peu importe, pour la personne qui va utiliser ce système. Donc, on n'a pas le droit de dire, l'UX ne me l'a pas dit, alors je n'y pense pas. Je pense qu'on doit même être critique, se poser des questions. Personne n'est parfait, moi le premier. Donc l'UX oui ils sont leur métier ils sont leur savoir-faire, ils sont leur expérience, ils ne pensent pas forcément à tout donc si on voit des choses qui nous surprennent, on doit au moins se poser la question ou poser la question pourquoi est-ce que c'était fait comme ça peut-être qu'il y a de très bonnes raisons pour lesquelles c'était fait comme ça et que du coup là on peut comprendre mais si on voit quelque chose, qui nous choque ou qui nous surprend ne pas poser la question ne pas se poser la question juste exécuter vêtements c'est presque être irresponsable.
Bruno:
Ça marche top merci beaucoup pour cette discussion.
Raul:
Raoul merci à toi j'aurais.
Bruno:
Deux dernières questions pour toi qui sont les questions rituelles de ce podcast la première c'est est-ce qu'il y a un contenu que tu souhaiterais partager avec l'ensemble des auditeuristes.
Raul:
Oui est-ce que je peux partager deux bien sûr donc le premier c'est, le travail qu'a fait Neil Ford de chez ThoughtWorks qui s'appelle Evolutionary Architectures donc il y a un livre, il y a aussi plusieurs présentations du Youtube qui durent une heure et quelques où c'est pratiquement le contenu du livre, j'aime bien le bouquin lui-même donc je trouve que c'est une très très, lecture très intéressante, parce que justement ça, Ça part sur tout un tas de questions qu'on peut se poser avant de commencer à coder ou pendant qu'on est en train de coder et qui ne sont pas forcément évidentes. Ce ne sont pas des choses auxquelles on va penser en premier, qui suivent un peu les mécanismes d'évolution avec la notion de fitness functions et autres. Donc ça permet d'apporter à n'importe quelle application n'importe quelle architecture des éléments d'évolution maîtrisés et non pas chaotiques même s'il y a des éléments de chaos qui vont venir, participer le deuxième quand on parlait des raccourcis qu'on fait, des biais c'est un livre qui s'appelle Thinking Fast and Slow je crois qu'en français le titre est système 1, système 2. Où justement ça parle de tout ce qui est les biais cognitifs le fonctionnement à niveau neurologique de notre cerveau et la psychologie qui est associée mais qui est quand même très ludique parce que l'auteur qui a quand même gagné un prix Nobel donc c'est pas un manche, mais il nous retrace un peu son histoire et les différentes expériences qu'il a fait autour de sa carrière les conclusions qu'il a tirées et en fait cette personne là est un peu le père fondateur de la neuropsychologie moderne. Quand on prend conscience de ces biais et de comment fonctionne notre cerveau dans des situations différentes, on peut justement les détecter et agir avant qu'ils ne soient un problème.
Bruno:
Ok, canon. On mettra bien évidemment des liens en description pour que les gens puissent les retrouver facilement. Et dernière question qui est la question la plus importante de ce podcast, est-ce que tu es plutôt espace ou tabulation.
Raul:
Tabulation.
Bruno:
Très bien. Merci beaucoup Raoul.
Raul:
T'en prie.
Bruno:
Et merci à tous d'avoir suivi cette conversation jusqu'au bout. Voilà, concentrez-vous sur vos utilisateurs. On est là pour apporter de la valeur, pour apporter des solutions. Mais pour ça, encore faut-il connaître le vrai problème qu'ils peuvent avoir. Et donc, il faut s'intéresser à eux. Il faut connaître un peu leurs problématiques. Donc, faites tout ce que vous pouvez pour développer cette connaissance-là. Et surtout, aussi comme toujours, je vous remercie de partager ce podcast autour de vous, vous avez accès aussi au Tipeee si vous voulez aider ce podcast à se développer, vous avez tous les liens en description ou sur les différentes plateformes sur lesquelles vous pouvez être et puis n'hésitez pas à mettre un commentaire 5 étoiles ça fait aussi remonter dans les applications d'écoute. Je vous remercie beaucoup je vous souhaite une très bonne fin de semaine, je vous dis à la semaine prochaine et d'ici là, codez bien.
