L'ergonomie, indispensable à l'adoption massive du libre - PSESHSF2016 — April MediaWiki\nL'ergonomie, indispensable à l'adoption massive du libre - PSESHSF2016\nRévision datée du 5 septembre 2016 à 14:01 par Morandim (discussion | contributions)\nTitre : L'ergonomie, indispensable à l'adoption massive du libre.\nIntervenants : Matthias Dugué (m4dz) - Luc Chaffard\nLieu : PSESHSF - Pas Sage En Seine - Hacker Space Festival\nDurée : 39 min 45\n4 11’ 28\n5 20’ 32\n6 30’ 38\nUne informatique libre est synonyme d’une société libre. Une adoption massive est nécessaire afin d’atteindre cet objectif.\nAfin d’y arriver, une interface utilisateur facile d'approche et ergonomique, construite avec le support de ses utilisateurs, est la clé.\nEn 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.\nMatthias : 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 !\nLuc : Ça va être un petit réflexe à prendre ça. Je suis Luc, le Product Designer de chez Cozy.\nMatthias : 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 des choses.\nPourquoi 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.\nPetite 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.\nÇ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 mousse. 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.\nLuc : Attention, moment Captain Obvious, si on veut une adoption de masse, il faut forcément rendre le produit accessible au maximum de gens.\nDonc, 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.\nMatthias : C’est Rage Against The Machine. C’est la slide corporate. 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.\nLuc : 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 des 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.\nMatthias : 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 pur et dur ? 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 vrai manque de dialogue et 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à.\nDonc 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...\nLuc : À travailler ensemble. Inaudible. Un, deux.\nMatthias : Tu as un choc de micro ! Interlude. Ah c’est possible. Ça fait de la lumière. Tiens, parle avec moi !\nLuc : On va se mettre avec Matthias. Bonjour Matthias. [Luc enlace les épaules de Matthias.]\nMatthias : Coucou les gens !\nLuc : 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.\nMatthias : Aller, au parc.\nLuc : 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 capables de partager ensemble.\nMatthias : Tu veux qu’on s’embrasse là ?\nLuc : C’est un peu cochon ça !\nMatthias : 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.\nLuc : Du coup l’ergonomie, eh bien késaco ? Qu’est-ce que ça veut dire ? C’est un joli terme.\nMatthias : J’aime bien késaco !\nLuc : C’est principalement ce qu’on utilise par le terme 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 ou 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’il ne pouvait pas avoir ailleurs. Ce n’est pas comprendre votre produit.\nMatthias : Ç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.\nEt 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 c’est celui 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.\nIl 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.\nLuc : On a souvent aussi une confusion entre le principe de design et d’ergonomie. Le principe de designen fait, souvent également appelé 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, je ne sais pas pourquoi. Et l’ergonomie, donc l’UX qui est là, sur la partie comportementale. Donc comprendre le behavior 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. »\nAprès toute cette belle théorie qu’on va 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 faire 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.\nDonc, 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.\nMatthias : Ç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.\nVous 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 : des 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 les 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.\nUne 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’interview, 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 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 part 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.\nLuc : 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.\nUne 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 font ce genre de choses. Je m’en excuse de donner des logiciels privateurs.\nMatthias : Pas encore !\nLuc : 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, 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.\nEn 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. 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.\nMatthias : 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 de chevaux plus rapides et pas forcément des moteurs à explosion.\nPourquoi 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 min, de 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 chose que les gens n’arrivent pas vraiment à comprendre, à maîtriser, mais ils sentent bien que c’est dans cette direction 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.\nDonc 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.\nLuc : 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.\nMatthias : 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 et 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.\nLe 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<design 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.\nReste une question, puisqu’on parle de <i<design, 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.\nFaire 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 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.\nMerci à vous et si vous avez des questions, on vous écoute.\nEt on a même un micro main. On va rigoler, on va se battre avec un petit micro HF.\nPublic : 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 ?\nMatthias : Tu veux répondre.\nLuc : 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.\nSur 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 essaient d’avoir en fait 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 fin un sprint de deux semaines, donc moi pendant deux semaines je travaille là-dessus, j’essaie de confronter les idées. 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.\nEt une fois que ça, ça a été validé, où 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. Et 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.\nMatthias : Merci. C’est-à-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.\nPublic : 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 ?\nMatthias : Tu veux répondre ou j’enchaîne ?\nLuc : Vas-y.\nMatthias : Eh bien écoute. 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.\nL’une des approches qu’on cherche à avoir là et rationalisée, c’est d’avoir un SDK, 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à, lors 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.\nPeut-ê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 que, 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 des éléments que vous pouvez facilement utiliser pour aller dans une direction qui nous semble être intéressante. »\nL’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 ?\nLuc : Non, je suis d’accord.\nMatthias : Ça m’arrange| !\nPublic : 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 ?\nMatthias : 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 Hacker Space, 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 ? »\nJe 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.\nPar 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 ?\nLuc : 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 on perd. 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é.\nMatthias : 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.\nRécupérée de « http://wiki.april.org/index.php?title=L%27ergonomie,_indispensable_à_l%27adoption_massive_du_libre_-_PSESHSF2016&oldid=72599 »


Un nouvel atelier radio en demi groupe.\nNous poursuivons les ateliers en demi groupe et cette semaine c’est le tour de : Fatou, Aychétou, Mustapha et Mounad de présenter leurs personnages.\nEn attendant l’arrivée de tout le monde, les garçons ont expliqué à Fatou (une nouvelle arrivante) ce qui s’était passé les séances précédentes.\nLes enfants étaient surprenamment calmes durant l’atelier qui a débuté par le jeu de la mémoire. Les règles sont simples, chacun tire un bâton au hasard et suivant sa couleur raconte une anecdote qui l’a marqué cette semaine.\nexemple : bâton bleu = un événement drôle, bâton noir = un événement qu’on a aimé, bâton orange = un événement qui nous a déplu.\nLes autres enfants doivent ensuite poser une question à l’anecdotier.\nCette activité en plus de démarrer la séance en douceur a permis d’introduire la notion de question et donc d’interview.\nAu fur et à mesure du jeu les enfants se livrent, racontent leurs vacances, exposent le déroulé de leur journée, expliquent comment ils pratiquent le ramadan...\nAu cours de la conversation, une drôle de coïncidence nous frappe et nous fait sourire : presque tout le monde est né en avril ! Les "bon anniversaire" fusent avec bonne humeur.\nAprès cette entrée en matière, les enfants finissent les blasons et se décident sur leur pseudo définitif. Puis, vient le temps de la restitution et de la présentation de leurs créations grâce à l’enregistreuse.\nLa consigne était la même que la séance précédente : “liberté totale”. Les enfants avaient carte blanche pour créer un blason qui les représente. Fatou et Aychétou nous ont rappelé que nous sommes aussi défini par ce qui nous tient à cœur en ajoutant : #blacklivesmatter à leur blason. Une occasion d’évoquer le racisme et la perception qu’en ont les enfants.\nLa séance s’est terminée sur un joli message de tolérance et de respect.\nTous les enregistrements de cette séance sont écoutables juste en dessous :\nGouttedoretvous · Atelier webradio GO&V x EGDO x Radio Campus : Lionne d'or\nGouttedoretvous · Atelier webradio GO&V x EGDO x Radio Campus : Aigle Noir\nGouttedoretvous · Atelier webradio GO&V x EGDO x Radio Campus : Yassin le chevalier\nGouttedoretvous · Atelier webradio GO&V x EGDO x Radio Campus : Drapeau américain


Joeyrasta - Aumilitaire\nJoeyrasta replied to Joeyrasta's topic in Questions juridiques\nBonsoir Inapte définitif à l'embarquement pour préciser. Oui il préfère garder des gens inaptes... je me doutais bien\nOui j'ai vu qu'il avait était traité beaucoup de fois mais moi c'est parce que j'ai étais déclaré inapte définitif depuis la signature du contrat que je demande ça. C'est pas pour raisons personnelles donc je pensais que ça pouvait être différent. Merci en tout cas\nJoeyrasta started following Joeyrasta and Annuler contrat non commencé January 15\nJoeyrasta posted a topic in Questions juridiques\nBonjour à tous. Mes meilleurs vœux pour cette nouvelle année qui commence. Je n'ai pas réussi à sélectionner la rubrique adéquate et je m'en excuse. je sais que ce type de questions a déjà était posé mais mon cas différe je pense. Je suis actuellement dans la Marine Nationale. Je suis maître, brevet supérieur technique et de spécialité non déficitaire. J'ai 19 ans et 3 mois de service à l'heure d'aujourd'hui. ( 20 ans en septembre 2022) J'ai signé un nouveau contrat de 3 ans en septembre 2020 pour m'emmener à 23 ans de services ( le nouveau contrat débute en septembre 2022). J'étais alors apte. Depuis octobre 2021 je suis déclaré inapte définitif a embarquer suite à un soucis que j'ai depuis la naissance ( découverte du soucis il y a 1 an environ). Actuellement je suis trimballé de bureau en bureau pour faire de l'administratif et ça me plaît pas du tout car ça ne correspond pas à ma formation initiale Ma première question : - puis-je trouver un " arrangement " avec l'institution pour ne pas commencer ce nouveau contrat en sachant que si j'avais su plus tôt de mon inaptitude définitive je n'aurai pas signé ce nouveau contrat ? Et ainsi je peux garder mes droits à chômage, reconversion ect... Deuxième question : - si je casse mon contrat, j'ai un préavis de 2 mois. L'institution peut-elle refuser ma résiliation sachant que je suis inapte définitif,spécialité non déficitaire,pas de lien au service. - si je casse mon contrat, vous confirmez pas de chômage, pas de reconversion ect ? Merci a tous.. Je préfère préciser que je ne souhaite pas des leçons de morale : tu as signé, c'est comme ça point barre. Bonne journée a tous.\nJoeyrasta replied to Joeyrasta's topic in Présentation des membres\nLa subtilité est que je ne voudrai pas résilier ce contrat ( qui n'a pas commencé d'ailleurs) de moi-même sinon je perds chômage, reconversion etc. Sachant que c'est pas juste une envie subite de ma part,c'est juste que mon aptitude a embarquer à changer depuis la signature et que je ne me vois pas faire de l'administratif pendant encore 3 ans et demi.\nJoeyrasta posted a topic in Présentation des membres