Description

Une informatique libre est synonyme d’une société libre. Une adoption massive est nécessaire afin d’atteindre cet objectif.
Afin d’y arriver, une interface utilisateur facile d’approche et ergonomique, construite avec le support de ses utilisateurs, est la clé.
En partant de l’approche développée par une équipe de libristes, Cozy Cloud, nous verrons comment écouter ses utilisateurs et les impliquer dans les étapes stratégiques du projet, du support au design en passant par le développement : les mains dans le cambouis, laissez vos utilisateurs hacker vos interfaces.

Transcription

Matthias :

Ce n’était pas prévu mais nous voilà quand même pour vous parler un peu d’ergo et de Libre et de la nécessité de travailler l’ergo et de faire de l’ergo intelligemment quand on veut faire du Libre, si on veut faire les choses bien jusqu’au bout. Alors qui qu’on est ? Ton micro, sinon les gens ne t’entendent pas en direct. Coucou les gens !

Luc :

Ça va être un petit réflexe à prendre, ça. Je suis Luc, le Product Designer de chez Cozy [1].

Matthias :

Moi je suis M4dz, je travaille chez Cozy également, je fais du dev d’interface, principalement. Avec Luc, on travaille conjointement sur le design et sur l’ergo des interfaces de notre produit. Notre produit c’est donc Cozy. Cozy, pour ceux qui ne savent pas, c’est une solution de serveur open source personnel, auto hébergeable. L’idée c’est de permettre aux gens d’installer leurs propres instances de serveur et, via des outils qui sont intégrés à l’ensemble, de pouvoir reprendre le contrôle sur ses données, de pouvoir se réapproprier tout ça, se libérer des GAFA ou des GAFAM, ou des GAFAMeee - mettez ce que vous voulez derrière - en gros, de redevenir vraiment possesseur de ce qu’on a et d’arrêter de disséminer un peu les choses.

Pourquoi je vous dis ça ? Pour une raison simple. C’est que, si on veut que ça marche et si on veut que les gens adhèrent à notre produit et s’en servent au maximum et donc se libèrent au maximum, on n’a pas le choix, il va falloir que ça passe par une adoption de masse, parce que tout seul on ne gagnera jamais la guerre. Et, pour cette adoption de masse, eh bien il faut que l’ergo soit au cœur de notre processus de réflexion, sinon, les amateurs éclairés pourront toujours s’en sortir ; les gens qui ont juste besoin que ça marche seront clairement perdus avec ça.
Petite démonstration par l’exemple. Ça c’est le bureau GNOME de 2002. Je ne vous fais pas le topo, GNOME, tout ça, etc. C’est tiré des notes de version de GNOME.
Ça c’est le bureau GNOME 3, 2011, dix ans plus tard - cinq ans déjà - et il y a quand même eu un gap assez énorme entre ça, qui était utilisable, mais qui piquait un peu et ça, qui est utilisable et qui est déjà un peu plus smooth. Après, on aime ou on n’aime pas, ce n’est pas forcément la question. Perso, GNOME n’est pas mon bureau de prédilection, mais, force est de constater que sur la même période de temps Mac OS faisait aussi un gap entre 2001 et 2010 avec une vraie progression en termes d’ergo et GNOME a suivi le même mouvement et, au final, on retrouve des paradigmes à peu près équivalents. Ça, ça a été très pensé au départ pour travailler sur de la tablette. L’idée c’est vraiment de permettre aux gens de s’approprier l’outil pour pouvoir s’en servir, parce que si on les force à utiliser un truc qui ressemble à Windows 95, ça va être un peu plus tendu quoi ! Donc il va falloir prendre ça en main dès le départ et il faut le penser.

Luc :

Attention, moment Captain Obvious, si on veut une adoption de masse, il faut forcément rendre le produit accessible au maximum de gens. Donc, prenons par exemple notre ami à tous Google, qu’on aime tous ici. Google, à l’époque, quand ils sont arrivés avec leur moteur de recherche, ils avaient juste un moteur de recherche. Leur plus gros concurrent, qui était en face d’eux, Yahoo, on arrivait sur leur site, c’était un peu de tout, de rien, des news, des images, enfin un gros n’importe quoi, et on sait maintenant qui est devant tout le monde à l’heure actuelle. Donc autant s’inspirer de nos ennemis pour mieux les combattre.

Matthias :

C’est Rage Against The Machine. C’est la slide corporate. Alors open source, ergo et design. Le statut de la relation entre les trois et les univers entre les trois, c’est que, eh bien c’est compliqué. C’est compliqué parce que l’open source, le Libre, l’ergo, et le design, ensemble, ils ont parfois du mal à dialoguer.

Luc :

Tout simplement, quand on arrive sur un logiciel libre, première phase à faire, l’installation pour la plupart des logiciels. Le commun des mortels n’a juste même pas envie. Ça demande des process compliqués, une documentation que la plupart des gens n’arrivent pas à lire. Il faut un bac + 15, les gens ne vont pas à ce stade. Et même pour le peu des élus qui y arrivent, ils arrivent sur une interface, certes, qui a des belles promesses, mais qui est juste inutilisable. Qui paraît cohérente pour un ingénieur, mais pour quelqu’un, on va dire, de plus normal, du commun des mortels, ça n’a aucun sens.

Matthias :

Tout ça, ça implique un vrai manque de confiance entre les différents acteurs qui collaborent au projet. Il y a des gens qui dev dans la salle ? Il y a beaucoup de devs dans la salle, qui font un peu d’interface, un peu de machin comme ça ? D’accord. OK . Il y a des gens qui font de l’ergo, pure et dure ? OK. Ouais, en mode comme ça quoi ! Voilà ! En brasse coulée ! En gros, l’un des principaux soucis, c’est qu’il y a un vrai manque de dialogue, un vrai manque de confiance entre les différents acteurs du projet. Quand vous développez une interface en tant que dev et que avez imaginé votre produit, vous, vous savez très bien où vous voulez aller donc, pour vous, c’est limpide. Ça ne le sera pas forcément pour l’essentiel des gens. Donc il faut collaborer avec des gens qui sont capables de vous apporter du savoir-faire, vous apporter de l’expérience, de l’expertise - des ergonomes, par exemple, des designers, entre autres - mais ça veut dire qu’il va falloir faire confiance à ces gens-là, il va falloir travailler avec ces gens-là et pas contre ces gens-là.

Le problème, c’est qu’on est dans une espèce de relation qu’on a nommée assez aimablement une relation « égosexuelle », je nomme le « aimablement » quand même, parce que, très vite, on en vient à faire de l’entre-soi. On fait un produit, on l’a pensé pour nous, on l’aime bien, c’est notre bébé, on l’a vachement pensé, on le raisonne énormément. C’est super ! Pas très inclusif, mais c‘est super ! Donc l’enjeu c’est d’apprendre à vivre ensemble, c’est d’apprendre…

Luc :

À travailler ensemble. Inaudible. Un, deux.

Matthias :

Tu as un choc de micro ! Interlude. Ah c’est possible. Ça fait de la lumière. Tiens, parle avec moi !

Luc :

On va se mettre avec Matthias. Bonjour Matthias. [Luc enlace les épaules de Matthias.]

Matthias :

Coucou les gens !

Luc :

[Si la femme de Matthias regarde, il ne se passe rien, je tiens juste à le dire.] En gros, la preuve en est, c’est parfait pour cette slide, Matthias est développeur frontpage, je suis designer, nous partageons la même culture. On fait tous les deux partie de la génération Dragon Ball Z. On a passé beaucoup plus de temps derrière notre ordi ou notre petite Nes plutôt que dehors à jouer au ballon.

Matthias :

Salopard !

Luc :

Je t’ai déjà vu jouer au ballon, excuse-moi Matthias ! Je ne suis pas bien en forme aujourd’hui. On partage des mêmes valeurs. On a peut-être un langage différent parce que, à un moment de notre vie, il y a en a un qui a choisi les crayons de couleur alors que l’autre a préféré se « focusser » sur l’ordinateur, mais, malgré tout, on partage des mêmes valeurs sauf que le langage est différent. Et c’est juste une communication qu’on a besoin de se réapproprier et être capable de ne pas juger l’autre parce qu’il n’utilise pas les bons termes. Et juste s’écouter et être capable de partager ensemble.

Matthias :

Tu veux qu’on s’embrasse là ?

Luc :

C’est un peu cochon ça !

Matthias :

Non, on ne va pas le faire. Du coup, il y a une très belle citation dont je n’arrive pas à retrouver la source, que je vais peut-être un peu démesurément attribuer à Stallman qui est en face, donc coucou, et qui dit : « Si le libre ne parvient finalement qu’à libérer que du code source ça sera un échec ». Si vous retrouvez la source, j’offre des câlins, vraiment ! Je n’arrive pas à remettre la main dessus. L’idée c’est vraiment de dire ouvrir des choses, c’est super, libérer des choses c’est bien. Si tout ce qu’on arrive à libérer, derrière, ce n’est que de la ligne de code, on aura perdu quoi ! La philosophie est nettement plus énorme que ça ! Elle va bien au-delà de tout ça !

Luc :

Du coup l’ergonomie, eh bien quésaco ? Qu’est-ce que ça veut dire ? C’est un joli terme.

Matthias :

J’aime bien quésaco !

Luc :

C’est principalement ce qu’on utilise par le terme d’UX qui veut dire user experience en anglais donc expérience de l’utilisateur. C’est le principe d’offrir une utilisation de votre produit sans friction. La personne qui va venir là, elle n’est pas là pour vous faire plaisir, elle est là pour qu’on lui simplifie la vie sur une tâche de son quotidien. Elle n’est pas là pour réfléchir comment votre produit fonctionne et pourquoi il y a ça ici, comment j’accède à ça, comment je configure telle chose ou quoi. Non ! La personne est venue parce qu’elle a un objectif, elle a compris une valeur ajoutée et son seul objectif, c’est d’être badass, c’est ce que vous lui avez vendu quoi : votre produit lui permet de résoudre des problèmes dans son quotidien qu’elle ne pouvait pas avoir ailleurs. Ce n’est pas comprendre votre produit.

Matthias :

Ça nécessite de savoir qui est votre utilisateur. Donc quand vous commencez à travailler sur une solution, quand vous commencez à réfléchir à un produit, vous avez une idée, un projet, un machin qui va changer la vie des gens - vous avez raison, on en a besoin - il faut déjà savoir à qui vous vous adressez. Savoir à qui vous vous adressez ça veut dire déterminer un ensemble d’utilisateurs, en marketing on parle de niche ou de marché. C’est ça ! C’est de savoir à qui vous voulez vous adresser. Parce que, simplement dire « mon produit s’adresse aux gens qui ont Internet », vous ciblez quand même une portion extrêmement large de la population. Ça va être extrêmement compliqué de les avoir. Donc il faut être suffisamment précis.

Et deuxième principe à garder à l’esprit, toujours, c’est que, même si vous avez imaginé votre produit, même si vous le connaissez, même si vous le savez, que vous le vivez, vous n’êtes pas un utilisateur avec un pouvoir de vote supérieur à celui des autres. Vous n’êtes qu’un utilisateur parmi tant d’autres. Ce n’est pas parce que vous avez votre usage et votre réflexion que ce sont ceux de l’ensemble des gens. Au contraire, votre usage sera souvent un peu biaisé parce que vous connaissez votre produit. Donc il faut garder ça à l’esprit.
Il faut déterminer un parcours utilisateur. Déterminer un parcours utilisateur, qu’est-ce que c’est ? Eh bien c’est déterminer quelle est la fonctionnalité phare de votre produit ou de votre solution. On ne fait pas des couteaux suisses, on ne fait jamais des couteaux suisses. La philosophie UNIX c’est ça, c’est un outil, une chose, et ça le fait bien, et ça ne fait que ça. Finalement, c’est ça qu’il faut appliquer quand vous concevez un nouveau produit, c’est que, même s’il y a une myriade de choses autour, vous avez une fonctionnalité qui est le cœur même de votre produit et c’est ça qui le fera vivre. Donc il va falloir trouver ce que c’est que cette fonctionnalité et il va falloir précisément déterminer comment on y accède et comment on s’en sert. À partir du moment où vous déterminez ce passage-là, ce parcours-là, le parcours de l’utilisateur, vous avez déjà libéré et défriché 60 % du boulot.
Luc : On a souvent aussi une confusion entre le principe de design et d’ergonomie. Le principe de design, en fait, souvent appelé également UI, User Interface, c’est la partie graphique de son interface. Donc c’est se dire « ce bouton va être bleu parce que le bleu renvoie à telle émotion ou renvoie à mon produit qui a choisi cette couleur pour x raisons. » Je ne fais partie de votre branding [image de marque, NdT], je ne sais pas pourquoi. Et l’ergonomie, donc l’UX qui est là, sur la partie comportementale. Donc comprendre le behavior [comportement, NdT] de votre utilisateur et de dire - je prends l’exemple d’un bouton qui est un peu ridicule, mais bon - de se dire « ce bouton je vais le placer à cet endroit, ça va être mon action principale, parce que sur cette page, à ce moment-là, c’est ce qu’il y a de plus cohérent pour mon utilisateur, c’est ce qu’il a envie de faire. »
Après toute cette belle théorie qu’on vous a dite, vous allez nous demander bullshit ou pas, quoi ? Je pense que ce n’est pas non plus trop compliqué de vous expliquer que ouais, forcément, ça va améliorer la satisfaction de votre utilisateur, pour la simple et bonne raison que votre produit n’est plus fait sans lui, mais il est inclus dans une boucle, avec lui. Donc chaque intervention sur votre produit est faite avec cette personne qui l’utilise. Donc forcément, ça va également augmenter votre rétention d’utilisateurs. Les personnes nouvelles qui vont arriver, de base, un produit qui a été fait avec d’autres gens comme elles, il y a de grandes chances qu’elles y restent et qu’elles se sentent à la maison. Et forcément, vous allez aussi réduire vos coûts de développement, pour la simple et bonne raison que vous allez arrêter de développer des trucs, perdre du temps en développement, l’envoyer dans la nature, voir ce qui se passe, ne pas savoir vraiment si c’est utilisé ou pas, les problèmes qui sont dessus, etc. Là vous rentrez dans une boucle où chaque chose qui est codée, en soi, a été validée. Donc ce ne sont plus des hypothèses, mais vous vous basez sur des données.
Donc, en gros, l’ergonomie qu’est-ce que c’est ? C’est créer une solution avec vos utilisateurs pour qu’ils se sentent à la maison, en fait. Tout simplement.
Matthias : Ça c’est bien beau, c’est de la théorie c’est super, voilà comment ça marche. Question c’est : comment est-ce qu’on fait ça ? Comment est-ce qu’on arrive à ce degré-là ? Une bonne pratique, qui est celle qu’on essaie de mettre en place le plus possible chez Cozy, c’est de travailler de façon user centric, donc travailler sur l’utilisateur, avec l’utilisateur, et ne pas le faire intervenir en fin de boucle. Ça veut dire que dès le départ, quand vous avez une hypothèse à valider, quand vous avez une idée qu’il va falloir confronter, on va déjà faire intervenir les utilisateurs, avant même que la feature soit disponible, avant même que ça soit codé, que ça soit enfoncé dans le code, on va commencer à en parler aux gens. On va commencer par leur dire « voilà, on a pensé à ça, qu’est-ce que vous en pensez ? » On va commencer à échanger avec les gens. Parce que travailler comme ça, ça va permettre de collecter des infos, de collecter leurs retours, de voir un peu ce dont ils ont envie, ce dont ils ont besoin. Synthétiser ces infos-là, les croiser, voir un peu ce qui s’en dégage, trouver les grandes tendances, les grands concepts, et puis en tirer quelque chose de concret, quelque chose que vous allez vraiment pouvoir utiliser.
Vous avez plusieurs moyens de faire ça. Vous pouvez passer par plein de canaux et, vraiment, je vous encourage à passer par plein de canaux parce que pour trouver les gens qui vont être accrochés à votre produit, vous n’avez pas le choix, il va falloir aller les chercher. Et vous ne pouvez pas aller les chercher si vous les faites sortir de leur zone de confort. Il faut aller les voir. Il faut aller les retrouver. Donc des canaux vous en avez plein : les forums, parce que c’est là que les utilisateurs lambda vont aller discuter le plus possible, l’IRC pour le support, les réseaux sociaux qui vont servir de levier pour attirer des gens, les plateformes de social coding pour pouvoir attirer des développeurs parce que les développeurs vont peut-être plutôt vous faire des retours sur des bugs et des tickets dans des issues, dans les plateformes de gestion, plutôt que de passer par les forums, etc. Donc c’est à vous d’être tentaculaire et ce n’est pas à vos utilisateurs de s’adapter à votre unique canal de discussion. Vous avez besoin d’adresser un maximum de monde.
Une fois que vous avez trouvé vos utilisateurs, l’important c’est de réussir à en tirer les informations dont on a besoin pour réussir à avancer. Donc ce sont des process d’interviews, c’est le concept idéal, finalement, plutôt en face à face ou en petits groupes. En tout cas, toujours avec une présence physique, même si ce n’est que de la visioconf, parce que ça va vous permettre, à un moment, d’avoir aussi une part de langage émotionnelle qui est importante. Il faut que les gens soient à l’aise quand ils discutent avec vous. Il faut que vous parliez à bâtons rompus de votre produit. Donc vous commencez. Vous, vous vous êtes défini un objectif. Vous savez ce que vous allez vouloir obtenir de votre utilisateur, quelles infos sont essentielles pour vous. Mais ce n’est pas comme ça qu’il faut le présenter à votre utilisateur. Il faut que ça soit une discussion sur un coin de table dans un bistrot. Il faut que le mec se sente bien. Même nous, d’ailleurs. Il faut que tout le monde se sente bien, que votre utilisateur soit bien et qu’il ait juste envie d’en profiter et que vous puissiez discuter de votre produit, vous soyez suffisamment neutre pour ne pas trop l’influencer, pas le guider, pas noter. Ne prenez pas des notes ! Prenez des notes après, évidemment, puisque vous en avez besoin pour revenir dessus, mais ne prenez pas des notes en même temps. Il n’y a rien de pire que de parler à un type qui prend des notes ! On a l’impression qu’il n’écoute pas ce que vous êtes en train de lui raconter. D’un seul coup, ça ferme les gens et puis il n’y a plus d’échange, de vrai échange concret, émotionnel. C’est de la discussion, c’est de la discussion simple. Mais ça marche bien ! Nous, on a des super retours quand on arrive à organiser des ateliers comme ça avec les utilisateurs. Alors, de par notre structure un peu décentralisée, on le fait par petits groupes, donc on fait cinq/six personnes et puis on discute un peu. Il en sort des idées qu’on laisse maturer après. Ce n’est pas grave, ça prend du temps, mais voilà ! Au moins, il y a des choses qui en ressortent et puis ça décante.
Luc : Une fois que vous avez collecté toutes ces données, c’est là où vous pouvez enfin retourner derrière votre petit bureau, enfin avec vous-même, et du coup, avec toutes ces informations, le plus gros challenge que vous allez avoir, à ce moment-là, c’est d’être capable d’extraire l’information. Les gens aiment dire des choses. Il y a une grande différence entre la demande et le besoin. Quelqu’un va essayer de dire n’importe quoi et, au final, il faut comprendre pourquoi il l’a dit. Comment, dans son usage, je pourrais, en fait, lui simplifier la vie ? Quelle est vraiment l’information à extraire de ce qu’il m’a raconté ? Être capable, aussi, de croiser, du coup, toutes ces informations collectées avec tous mes utilisateurs. Être capable de prioriser ce qui est important dans ce qu’on m’a dit. Où je vais ? Où sont sont mes erreurs ? Qu’est-ce que j’ai fait de complètement ridicule ? Pourquoi les gens n’arrivent pas à faire telle action sur telle page ? Apprendre, du coup, de toutes ces données, en les croisant.
Une fois que vous avez tout ça, c’est là où vous pouvez vous amuser avec votre petit papier à faire, des petits wireframes, qui est de faire des sketches sur papier ou, si vous êtes plus à l’aise, vous pouvez directement partir sur Gimp à faire des formes un peu plus simplifiées. Si vous sentez encore plus à l’aise, vous pouvez vous amuser à mettre votre charte graphique à l’intérieur pour donner une sensation un peu plus réelle. Si vous êtes vraiment motivé, vous pouvez aller même jusqu’à utiliser des prototypes dynamiques type, InVision ou Marvel. Je n’ai pas, je ne connais pas de logiciels open source, malheureusement, qui fassent ce genre de choses. Je m’en excuse de donner des logiciels privateurs.
Matthias : Pas encore !
Luc : Pas encore, mais j’espère que ça va donner des idées à certains. Et en fait, ces prototypes dynamiques permettent, à travers des images, de mettre des zones cliquables et de donner l’impression d’une vraie app codée, alors que non, c’est juste du bluff. Ce sont des images et on clique et ça nous envoie à un lien vers une autre image. Et rien qu’avec ça, en fait, on peut de nouveau tester rapidement sans développement. Ça prend, en général, pas plus de quelques jours, quand on commence à être un peu à l’aise dessus et, une fois de plus, ça permet de collecter de l’information, de collecter de nouveau de l’information sur ce qu’on a fait, rapidement, genre sketcher sur un bout de papier. En terme général, vous avez une idée, vous avez fait attention à ce que les gens vous ont dit. Vous challengez ce que vous avez appris avec vos hypothèses. Vous pouvez vous amuser, du coup, à le mettre sur papier. Hop, un petit message sur IRC, un petit message sur le forum. Qu’est-ce que vous en pensez ? Est-ce que je vous ai bien compris ? Est-ce qu’on va dans le bon sens ? Etc. Passer, comme ça, à différentes étapes, apprendre, itérer, être capable, du coup d’améliorer ce que vous avez dessiné. Être capable de réparer si c’était directement sur du développement et même, si vous étiez juste dans cette phase de design, là, vous pouvez passer sur une phase de développement où, du coup, vous perdez beaucoup moins de temps et votre développement a beaucoup plus de sens.
En soi, vous arrêtez de développer pour voir, puisque vous savez déjà, vous avez collecté les data, vous êtes déjà dans la validation. Donc maintenant, vous pouvez juste rester focus sur le développement. Et, tout simplement, on répète à chaque fois qu’on fait quelque chose, toujours redemander à sa base d’utilisateurs, voir ce qu’ils en pensent. On en arrive au cycle Lean, très simple, qui est « je construis, je mesure et j’apprends », etc.,etc.,etc. Dès que je balance quelque chose, dès que j’ai une hypothèse, il faut la confronter avec les gens, être capable d’avoir de l’information des gens qui utilisent quotidiennement votre produit.
Matthias : Seconde citation, on aime bien, de Henry Ford cette fois, qui disait simplement que s’il avait vraiment écouté ses utilisateurs complètement, la seule chose qu’on lui aurait demandée, c’était des chevaux plus rapides et pas forcément des moteurs à explosion.
Pourquoi c’est pertinent dans notre cas ? C’est pertinent parce que vous avez besoin de ce support de vos utilisateurs. Vous avez besoin de travailler avec eux, main dans la main, pour pouvoir avancer sur votre produit, aller dans la bonne direction. Après, votre produit vous l’avez imaginé, vous l’avez conçu, vous en portez la vision. Et cette notion de vision est super importante parce que, quoi que vous fassiez, quoi que vous expliquiez à vos utilisateurs, il y aura toujours une part d’inconnu par rapport à votre vision, une part de choses que les gens n’arrivent pas vraiment à comprendre, à maîtriser, mais ils sentent bien que c’est dans cette direction-là qu’il faut aller. Vous, votre devoir, c’est d’être inspirant vis-à-vis de vos utilisateurs. C’est de faire en sorte que ça les pousse à aller plus loin dans votre produit et que vous puissiez avancer avec eux. Mais vous restez garant de cette vision ; vous êtes le garde-fou. Après, les chemins qui vont être pris vont vous être dictés par vos utilisateurs, mais l’endroit où aller, c’est vous qui l’avez en tête, et il ne faut pas perdre ce point-là de vue.
Donc si je résume, pour faire simple : il faut discuter avec les utilisateurs ; il faut diversifier les canaux ; il faut aller chercher les gens au maximum et non pas les pousser à venir vous voir : il faut que ce soit vous qui ratissiez. Il faut que vous appreniez de vos utilisateurs, vous tiriez les enseignements de tout le travail que vous faites avec eux et quand je dis avec eux, c’est vraiment travailler avec les gens. Et surtout conserver toujours le contrôle de là où vous voulez aller, de votre solution, de ce que vous voulez faire, mais en étant le plus inclusif et le plus participatif possible.
Luc : Donc en résumé, le principe même c’est : soyez inclusif, mais soyez-le réellement ! Soyez réellement à l’écoute de vos utilisateurs. Essayez de comprendre, de vous mettre à leur place. Arrêtez aussi de le prendre personnellement : une critique, ce n’est pas vous qu’on juge, c’est votre travail. Vous n’êtes pas votre travail, vous n’êtes pas votre produit. Les gens sont là, quand ils vous donnent une critique négative, ils sont là pour aller dans le bon sens, pour améliorer votre produit pour que les gens apprécient votre produit, l’utilisent. Et ça n’a jamais été une critique par rapport à vous, vos compétences, ou quoi que ce soit. Il faut être capable de faire la différence entre la personne que vous êtes et le travail que vous fournissez.
Matthias : Deuxième bon conseil - enfin bon conseil, vous en faites ce que vous voulez, c’est cadeau, hop ! - deuxième conseil : l’ergo ce n’est pas le design. Faire de l‘ergo, je vais faire un raccourci rapide, je vais dire « tout le monde est capable de faire à peu près de la bonne ergo ». En gros, tout le monde est capable d’être de bon conseil à partir du moment où il comprend les enjeux de votre produit, pour vous donner les bonnes directions, pour vous montrer, si jamais vous prenez une direction qui n’est pas forcément la bonne. Tout le monde n’est pas ergonome, nuance, tout le monde peut apporter sa pierre à l’édifice. Donc ça c’est important et ça, ça va dans la bonne direction.
Le design c’est ce qu’on disait tout à l’heure, c’est quelque chose qui est plus émotionnel. C’est quelque chose qui est plus lié à du comportement, à une image de marque, à ce que vous voulez mettre derrière, au message que vous voulez véhiculer et ça, c’est plus compliqué. Tout le monde ne sera pas de bon conseil. La nièce de la coiffeuse de la belle-sœur de votre femme, ne sera pas forcément la meilleure pour vous dire que « oui, le bleu c’est mieux ! » Non ! Il y a des considérations à prendre : votre marque, votre produit, ce que vous imaginez, vous l’avez en tête. C’est important de travailler dans cette direction-là. Donc écouter les gens, oui, sur certains conseils, pas sur d’autres. Sur de l’ergo c’est bien, sur du <i c’est plus compliqué. Quoi qu’il en soit, encore une fois, l’idée c’est de travailler avec les gens. Faites intervenir des ergonomes. Faites intervenir des designers. Étendez votre champ de compétences autour de vous parce qu’on a tous des savoir-faire différents. Et là où les gens seront de bon conseil en ergo, ils ne le seront pas forcément en dev, et inversement. Donc on peut tous faire des choses bien. Si on veut vraiment les pousser jusqu’au bout, il faut s’entourer des bonnes personnes, il faut travailler le plus possible avec les gens.
Reste une question, puisqu’on parle de <i, c’est : est-ce qu’on peut open sourcer du design ? Vraie question. Vraie question compliquée. Open sourcer de l’ergo, c’est ce qu’on raconte depuis une petite demi-heure, c’est possible, ce n’est pas très difficile, il suffit d’être assez inclusif avec les gens et de faire travailler les gens ensemble. Ce n’est pas très difficile sur le papier, dans la réalité il faut être open man, mais c’est toujours possible. Donc faire de l’open source en ergo c’est jouable.
Faire de l’open source en design, ça veut dire faire intervenir des gens sur votre image et sur le message que vous voulez véhiculer. C’est moins simple. C’est pour ça qu’on est vachement attentifs à cette distinction entre ergo et design. Il y a vraiment une frontière entre les deux, qui est ténue, parce que les ergonomes font du design et inversement. Et effectivement, envoyer un frame sans les codes couleurs qui vont avec, ce n’est pas forcément efficace. Donc il faut garder un peu de nuance là-dessus. Mais open sourcer du design est-ce que c’est jouable ?
Il y a une initiative de Mozilla, en ce moment, qui travaille à une vision open source de leur marque. Donc ils essaient d’open sourcer l’image de marque de Mozilla et de voir comment ils arrivent à le faire vivre. Ça date de quelques semaines, c’est une initiative qui est très jeune. Peut-être que ça va marcher. Peut-être que ça ne va pas marcher. Pour le moment on n’en sait trop rien, l’avenir nous le dira, mais, en tout cas, c’est une expérience intéressante. Nous, on tente le pari aussi la semaine prochaine puisqu’on a des ateliers en meet-up et on a notamment un atelier dédié à l’image de Cozy. Donc on va tenter la même chose : faire participer les gens, faire participer les utilisateurs, dialoguer un maximum autour de ça. Peut-être qu’on va se planter ! C’est possible ! Ce n’est pas grave ! Il y a peut-être de grandes chances ! On se prendra un mur, ce n’est pas grave, mais au moins, on aura essayé. En tout cas, l’idée c’est de se dire « il n’y a pas que sur du code qu’on peut faire intervenir des contributions. Il n’y a pas que sur du code qu’on peut faire intervenir des gens. Il y a plein d’autres domaines autour. » Et si on veut que notre solution soit adoptée par le plus grand nombre, eh bien on n’a pas le choix, il va falloir faire participer ce plus grand nombre.
Merci à vous et si vous avez des questions, on vous écoute.
Applaudissements
Et on a même un micro main. On va rigoler, on va se battre avec un petit micro HF.</i</i

Public :

Bonjour. J’ai une question. Comment faire, justement, dans le cas d’un développement distribué ? On imagine qu’on est en agile parce que sinon ça n’a pas trop de sens. Donc ça veut dire rendre compte du board, du kanban, enfin peu importe, il faut que ça, ce soit public, en fait, j’imagine. Ça veut dire très bien décrire les objectifs de chaque story. Qu’est-ce que ça serait vos conseils ou les pratiques que vous mettez en place et que vous avez déjà expérimentées ?

Matthias :

Tu veux répondre.

Luc :

Nous, juste chez Cozy, en fait souvent, quand on a des tout petits problèmes où on voit strictement qu’il y a une fonctionnalité qui n’a vraiment aucun sens et que les gens nous demandent comment faire, là, en terme général, on comprend. Ce sont des gens qui se plaignent soit via GitHub, qui peuvent se plaindre aussi également via le forum. Là forcément on se dit « un nous le dit, ouais, on n’a pas le temps. Deux, trois, quatre, ça commence à arriver en top priorité. » Là on fait un petit fix rapidement, sans se poser trop de questions.

Sur des features un peu plus complexes, donc il y a ces phases qu’on fait en début de milestone qui sont des interviews utilisateurs. Nos Product Owners, en fait, essaient d’avoir entre cinq et dix interviews d’utilisateurs, histoire de comprendre l’usage des utilisateurs, à l’heure actuelle, sur leur Cozy, comprendre pourquoi ils utilisent Cozy, savoir si c’est juste une question de valeur ou si c’est également parce qu’on leur simplifie un peu la vie. J’espère qu’on en est un peu là, quand même ! En fait, en comprenant du coup leur usage, comme on a dit tout à l’heure, on croise toutes ces données et là, on comprend où aller. Et souvent, c’est là où il y a des fonctionnalités un peu plus complexes qui vont arriver, et c’est là où moi j’interviens, où je vais commencer à designer cette partie-là. Et là, on fait intervenir, une fois qu’on a fini un sprint de deux semaines, donc moi pendant deux semaines je travaille là-dessus, j’essaie de confronter les idées,etc. Et là, on va faire un petit post sur le forum qui va être ensuite pingué via Twitter, via IRC, etc., pour que les gens l’utilisent. Donc souvent j’utilise ce prototype dynamique où les gens peuvent cliquer, etc., et les gens peuvent même mettre des commentaires directement sur le design pour me dire « là ça n’a pas de sens ; là tu es trop designer pour moi, tu es un hipster, vas-y, rentre chez toi ! », ce genre de choses. Et de là on comprend : on s’est peut-être un peu trop enflammés, on va retravailler ça, etc. Et en fait, on rentre dans une boucle comme ça de feed-back look. Tant que les gens - ce n’est même pas nous qui sommes satisfaits - c’est tant que les gens, nos utilisateurs du quotidien, ne sont pas satisfaits par ce qu’on leur a proposé, on ne rentrera pas en phase de développement, en fait.
Et une fois que ça, ça a été validé par les gens - il y a toujours un type qui n’est pas content, mais celui-là on ne pourra jamais l’avoir ce n’est pas grave - là on peut rentrer, du coup, faire des petites cartes Trello ou GitHub, répartir, couper cette tâche, cette fonctionnalité, pour qu’elle rentre, du coup, en agile sur des sprints de deux semaines, etc. Et toujours remettre en question le travail qu’on a fait.

Matthias :

Ça veut dire qu’on a des process de développement qui sont en cycle rapide, quinze jours, sur des milestones de trois mois. C’est vraiment interne à ce qu’on fait, donc c’est librement adaptable, mais on est très bien conscients qu’une nouvelle fonctionnalité peut mettre plus de temps à arriver, en fait. Parce que, effectivement, ces échanges avec les utilisateurs sont importants à prendre en main. Après, ça veut dire aussi qu’une fois qu’on le met en prod, généralement, on est plutôt bien partis, donc on ne va pas trop faire de rétropédalage.

Public :

J’ai une petite réflexion sur le design par rapport au logiciel libre, surtout un logiciel libre qui veut s’ouvrir à un maximum de gens. Je caricature un peu, mais je vois deux grandes tendances. Il y a la tendance iPhone où, en gros, le design s’impose à toi parce qu’il a été prédéfini pour toi et, même si tu cherches à développer sous iPhone, tu es dans une round map, tu ne peux pas faire autrement, etc. Et je dirais, la version extrême de l’autre côté, c’est le CyanogemMod, dans lequel tu peux tout paramétrer, jusqu’à la taille du petit pixel de n’importe quoi. Vous qui avez un logiciel qui veut à la fois être open source et se diriger vers le plus grand nombre, comment vous avez trouvé l’équilibre entre les deux ?

Matthias :

Tu veux répondre ou j’enchaîne ?

Luc :

Vas-y.

Matthias :

Encore une fois, je pense que c’est une question de curseur et c’est une question d’ajustement. Peut-être qu’un élément de réponse ça va être de commencer à fournir aux gens de quoi structurer leur réalisation et leur produit tout en restant dans la philosophie Cozy. J’explique un peu l’idée. L’idée de Cozy c’est que derrière il y a une espèce d’App Store, de marché quoi, dans lequel des développeurs peuvent proposer leurs applications pour faire tourner sur Cozy. Si vous êtes développeur et que vous voulez faire des applications sur Cozy, venez ! C’était la slide branding. L’idée c’est de se dire que, partant de là, on n’impose rien, donc effectivement, on laisse librement les développeurs travailler sur leur produit. On n’impose rien au niveau du design, on n’impose pas grand-chose. On commence à avoir des guidelines qui commencent à se structurer, mais ce sont encore des raquettes un peu trouées dans lesquelles il faut qu’on enrichisse beaucoup de choses. C’est très long, ça prend beaucoup de temps et d’énergie.

L’une des approches qu’on cherche à avoir là et à rationaliser, c’est d’avoir un SDK [software development kit, NdT], un petit framework dédié au front et qui fournisse un maximum de composants d’interfaces qui soient prédesignés, qui puissent être faciles à customiser, de façon à ce qu’on puisse les adapter, mais qui puissent être aussi utilisés comme briques de base pour monter des interfaces. Après, on veut les utiliser, on les utilise ; on ne veut pas les utiliser, on ne les utilise pas. Et ce n’est pas grave, et on ne va jamais râler parce qu’une interface n’utilise pas le SDK de Cozy. À la limite on s’en fout ! Les premiers utilisateurs de ce truc-là, alors hop-là je me fais un tacle tout seul, mais ce n’est pas grave, pour le coup ça va être nous. C’est-à-dire que nous, pour développer des apps, ça va être super pratique de pouvoir avoir cet outil-là et de mutualiser un maximum de choses.
Peut-être qu’un bon élément de réponse, ça peut être des choses comme ça. Des éléments sous-jacents qui sont des notions organiques simples. J’aime bien la notion de design atomique où on se dit, finalement une interface c’est quoi ? Eh bien c’est comme un organisme, et cet organisme se décompose en sous-parties qui sont des organes, qui eux-mêmes se décomposent en sous-parties qui sont des molécules et qui elles-mêmes se décomposent en sous-parties qui sont des atomes. Et cette notion de design atomique un peu organique, est intéressante dans ce qu’elle permet, si on s’adresse plutôt sur la couche basse, donc plutôt la couche atomes et molécules de dire « eh bien voilà, on vous fournit déjà des éléments que vous pouvez facilement utiliser pour aller dans une direction qui nous semble être intéressante. »
L’autre bonne approche, eh bien c’est ce qu’on dit depuis tout à l’heure, c’est faire de l’open source ergo. C’est de ne jamais prendre les décisions de façon trop arbitraire et d’inclure les gens au maximum. Si les composants, à la base, ont déjà été pensés avec les gens pour que ça soit le plus pratique pour eux, eh bien on se sauve la vie sur pas mal de trucs derrière. On se sauve du temps, surtout. Mais c’est du curseur à ajuster et on n’aura jamais tout le monde. On ne satisfera jamais tout le monde et, en même temps, avoir une position hyper dictatoriale ce n’est pas très intéressant non plus. Donc il faut ajuster. C’est comme la sécu quoi, il faut ajuster entre « est-ce qu’on laisse tout ouvert ? » ou « est-ce qu’on ferme tout ? », mais on n’a plus personne parce que c’est super chiant à utiliser. Tu veux rajouter un petit truc ?

Luc :

Non, je suis d’accord.

Matthias :

Ça m’arrange| !

Public :

On a une question sur Twitter. On a parlé d’ergonomie et de design et quid de l’accessibilité qui est généralement le gros parent pauvre quand on fait des applications ?

Matthias :

Oh ! Yes ! Alors pour la petite anecdote, je ne sais pas qui a posé cette question sur Twitter, je lui fais des bisous. Pour la petite anecdote, il y a eu changement de programme tout ça, à Pas Sage En Seine, et en fait, la conf qu’on est en train de donner là, on l’a donnée il y a deux heures au HackerSpace, là-bas. On me dit là-bas en fait, donc je suis très mauvais en orientation. Et c’est rigolo, parce que cette question est arrivée quasiment dans les mêmes termes. Et donc la question qui avait été posée, c’était « est-ce qu’on peut se servir des référentiels d’accessibilité qu’on a, ou des recommandations d’accessibilité qu’on a, pour pouvoir servir de base à une bonne ergonomie ? »

Je vais faire la même réponse, parce que j’en étais très satisfait ! C’est de dire qu’on a des super référentiels d’accessibilité, sur le Web et en France. L’un des gros problèmes c’est que ces référentiels d’accessibilité, si on veut intégralement les implémenter, déjà c’est une tannée sans nom et, en plus, on se retrouve avec des interfaces qui sont généralement assez mal fichues au final, parce qu’eux ils adressent, ce n’est pas beau ce terme je suis désolé, ils cherchent à résoudre un ensemble de problèmes qui est tellement dense et tellement vaste et tellement complexe que c‘est se dire « je vais tout implémenter pour dire je vais tout implémenter et avoir une super note ! » C’est bidon, ça ne sert à rien.
Par contre, ce qui est intéressant, c’est de se dire qu’on est 80 % de la population en situation de handicap. Porter des lunettes, vous êtes en situation de handicap. Vous êtes obligé de faire comme ça pour pouvoir lire [Matthias tend le bras], vous êtes en situation de handicap. Vous vous retrouvez dans le métro avec votre téléphone avec un fond de edge qui ne passe pas, vous êtes en situation de handicap. Donc cette situation de handicap existe partout, tout le temps ; elle est variable : des fois vous le serez, des fois vous ne le serez pas. En tout cas, ça s’adressera toujours à vous. Donc utiliser l’accessibilité comme moteur à une bonne ergo, comme une base de travail, c’est hyper intéressant. L’appliquer bêtement et de façon irraisonnée, ça ne résoudra pas plus les problèmes de vos utilisateurs, à la limite, ça pourra peut-être en créer. Tu veux compléter ?
Luc : C’est souvent le problème de choses comme ça qui sont définies pour une certaine catégorie de personnes qui va, forcément du coup, très bien répondre à ces gens-là mais qui, au contraire, va être un problème d’accessibilité pour tous les autres. Typiquement, quelqu’un nous a posé la question suite à cette discussion aussi de, par exemple, le produit, si quelqu’un est aveugle comment on fait ? Il est venu avec la solution simple de dire « ouais, on met un gros bouton spécial gens aveugles », qui correspond peut-être à 1 % des utilisateurs et peut-être que là je m’emballe même encore. Et le problème de ça c’est : pour qu’il le voie, le bouton, il faut forcément qu’il soit gros, mais on répond juste à une personne qui va, au contraire, polluer l’interface, du coup pour tous les autres qui vont nous faire : « Mais pourquoi vous faites ça ? » Donc, c’est aussi un peu la complexité de savoir comme tu as dit, de trouver le bon équilibre. Typiquement, un cas d’accessibilité assez simple, c’est savoir jouer des contrastes. On est de plus en plus sur des écrans qui tendent avec une qualité magnifique, avec écran Retina, enfin c’est splendide ! Et, malheureusement, il y a très peu de gens qui les ont et la plupart des gens sont encore sur des écrans avec des résolutions pas top et avec des contrastes qui ne les gèrent pas aussi bien. Ce qui fait qu’on se retrouve sur des cas assez compliqués où les gens n’arrivent même pas à lire ce qu’on a mis, et, en fait, l’ergonomie perd pour le design. C’est là où il faut faire attention. Je pense que ce sont des petits cas comme ça où il faut faire attention aux cas d’accessibilité.
Matthias : Et c’est là que travailler avec les utilisateurs c‘est important. Encore une fois vous développez une solution pour un ensemble de personnes données. Si, effectivement, 90 % de votre public c’est un public malvoyant, forcément il faut le prendre en compte dès le départ. C’est évident ! Est-ce qu’il y a d’autres questions ? Merci beaucoup.
Applaudissements.
[footnotes /]