Et si on tenait compte des utilisateur·ices dans les projets libres ?

Eh oui, chez Framasoft, on n’a pas peur d’utiliser des titres (légèrement) provocateurs — certain·e⋅s diraient même pièges à clic — quand on a envie de vous parler de sujets que l’on juge vraiment importants.

Et aujourd’hui c’est… l’UX Design dans les projets libres !

« UX-kwa ? Un logiciel libre, c’est créer du code qui fonctionne sans bugs, lui mettre une licence libre et c’est bon, non ? »
Alors, oui, mais pas que. Du coup on va faire le point avec vous sur ce qu’est l’UX Design et pourquoi c’est important (surtout pour le libre).

Et pour ça, on va vous raconter une première expérimentation réalisée lors du Framacamp !

Framacamp : la colonie de vacances de Framasoft ?

Il y a deux évènements annuels très très importants pour Framasoft :

  • l’Assemblée Générale de l’association (AG), où on va faire les bilans moraux et financiers, ainsi que définir les actions et les campagnes à venir,
  • et le Framacamp !

Le Framacamp, c’est l’occasion pour les salarié·es et les membres de l’asso de se réunir de manière conviviale pour se rencontrer, tisser des liens, boire des coups, délirer et surtout débattre, faire avancer les projets et expérimenter.

Au cours du Framacamp, Maïtané a proposé un atelier « Méthodes UX » pour présenter 4 méthodes utilisées par les UX designers et les faire tester aux développeur·ses sur place.

Alors déjà, c’est quoi l’UX Design ? UX Design, ça veut dire User Experience Design en anglais, ce qui revient à Design de l’Expérience Utilisateur·ice en français. C’est une discipline qui a pour objectif de prendre en compte les besoins, les attentes et les usages des utilisateur·ices visé·es pour proposer un service ou outil qui leur convient le plus possible et leur proposer une expérience positive. C’est donc très loin de « juste » réaliser des maquettes graphiques !

Pourquoi parler d’UX avec des devs ? Parce que tout le monde est convaincu chez Framasoft que le logiciel libre c’est bien, mais s’il est utilisé par un maximum de personnes c’est quand même mieux. Et il n’y a pas moyen de demander aux utilisateur·ices d’utiliser des logiciels qui ne sont pas correctement conçus, ou qui ne prennent pas en compte leurs besoins.

C’est un peu ça. L’UX, c’est créer des logiciels :

  • utiles (car ils apportent de la valeur aux utilisateur·ices) ;
  • utilisables (car ils peuvent être utilisés sans provoquer (trop) de frustration) ;
  • et utilisés (car du coup les utilisateur·ices ont envie de… les utiliser !).

 

Du coup, pour comprendre ce qui se passe dans la tête des utilisateur·ices, les UX designers ont tout un panel de méthodes et de techniques. Au cours de cet atelier « Méthodes UX », nous en avons testé quatre :

  • Le test des 5 secondes
  • L’AttrakDiff
  • Les courbes d’évaluation UX
  • Les tests utilisateur·ices.

Il existe évidemment un très grand nombre de méthodes, selon les étapes du projet, les objectifs visés, le nombre de participant·es (présent·es ou à distance), etc. Si vous souhaitez en découvrir d’autres, nous vous conseillons l’excellent ouvrage Méthodes de Design UX : 30 méthodes fondamentales pour concevoir et évaluer les systèmes interactifs, de Carine Lallemand et Guillaume Gronier.

 

Les méthodes de cet atelier ont notamment été choisies en s’inspirant de l’atelier qu’ils ont donné ensemble à ParisWeb 2015.
Il s’agit de méthodes plutôt simples à comprendre et complémentaires pour prendre le pouls de son projet du point de vue de l’expérience utilisateur.

Note anti-troll : les participant·es étaient quasi exclusivement des membres de Framasoft, donc pas vraiment représentatif·ves du public réel des outils testés, nous en sommes bien conscient·es. En temps normal, on aurait dû composer un panel réaliste de participant·es mais on n’avait pas d’autres cobayes sous la main !

Le test des 5 secondes

Pour tester quoi ?

La première impression qu’ont les utilisateur·ices en voyant une interface.

Comment on fait ?

On montre un écran d’une interface (logiciel, application mobile, site web, …) pendant 5 secondes, puis on pose quatre questions, qui permettent de connaître les a prioris des utilisateur·ices lorsqu’ils découvrent l’interface, et ce qu’ils en retiennent. Pratique si vous voulez savoir si votre interface est compréhensible au premier abord.

Cas pratique

Maïtané nous a fait essayer cette méthode sur une maquette d’interface de création de pads collaboratifs.

Maquette de l’interface de création de pads collaboratifs du Mouvement Colibris — Chez Framasoft, on propose le même service via https://framapad.org

 

Nous avons donc eu 5 secondes de visualisation de la page avant de pouvoir répondre aux questions.

Et là… révélation ! Sur la troisième question (définir les objectifs du système), on s’est aperçu qu’une des fonctionnalités n’était pas claire pour tout le monde.

Et donc, en à peu près 3 minutes de test, sur un groupe d’à peine 10 personnes, nous avions déjà relevé un problème d’ergonomie suscitant de l’incompréhension chez plusieurs d’entre nous, malgré l’interface très simplifiée. Pas mal pour un début !

Et si vous avez plusieurs prototypes, cette méthode peut permettre de soumettre chacun à un groupe différent pour comparer les résultats :

Les trois visuels ont été réalisés par Kristof Dreano, graphiste des Colibris, et sont disponibles sous licence Creative Commons BY SA.

L’AttrakDiff

Pour tester quoi ?

Pour analyser quantitativement l’expérience utilisateur, suivant ses qualités pragmatiques (j’ai l’impression que le produit me permet de réaliser ma tâche facilement) et hédoniques (j’ai envie de l’utiliser, ça me fait plaisir de l’utiliser)

Comment on fait ?

L’AttrakDiff est un questionnaire standardisé, il y a donc « juste » à récupérer la grille de questions, la grille d’analyse  et hop ça fait des Chocapics !

 

 

 

Un exemple de rendu final :

Source : UXmind.eu

Cas pratique

Pour l’atelier lors du Framacamp, on a pris le cas de Framadate avec une grille de questions plus réduite que celle normalement utilisée. Après un rapide dépouillement des résultats, on découvre sans trop de surprise que Framadate est un outil très « orienté tâche », c’est à dire fonctionnel et pragmatique mais qu’il lui manque un aspect attractif et procurant une expérience plus positive. Une tendance courante du libre ?

Les courbes d’évaluation de l’expérience utilisateur·ice

Pour tester quoi ?

Les courbes vont représenter, au cours du temps, les ressentis des utilisateur·ices sur différents points (que se soit l’expérience utilisateur·ice générale, son attractivité, sa facilité d’usage, …), ce qui permet d’avoir une vision sur la durée des différentes améliorations et détériorations !

Comment on fait ?

On demande à l’utilisateur·ice de tracer une courbe, en mettant en abscisse sa relation envers le produit (de « très positive » à « très négative ») et en ordonnée le temps. Dans l’idéal, elle place à certains endroits les événements marquants de son expérience, pour que l’on sache à quoi est dû un changement de direction de la courbe.

Cas pratique

Vous pouvez le faire chez vous, là, tout de suite ! Un papier, un crayon, et vous pouvez noter l’évolution dans le temps de votre rapport à Twitter par exemple ! Ce qui est assez marrant à voir, c’est la dégringolade de l’adhésion à Twitter lorsque Mastodon est apparu, mais vu le public testé ce n’était pas très étonnant. 😉

Le meilleur pour la fin : les tests utilisateur·ices !

Pour tester quoi ?

Ben, ce que tu veux, en fait !

Comment on fait ?

On demande à l’utilisateur·ice de réaliser une « mission » qui est cohérente avec sa potentielle utilisation du logiciel. L’idéal c’est de le-la laisser assez libre, pour observer de quelle façon iel va remplir sa mission (on peut être surpris !). Ensuite, on lui demande de bien vocaliser ce qu’iel fait, pour qu’on puisse suivre son schéma de pensée.
Du côté des développeurs·euses, il est très important de ne pas intervenir au cours du test. Même si ça vous démange « mais le bouton est juste là ! »  et qu’on a très très envie de le montrer à l’utilisateur·ice. Le mieux à faire c’est de prendre des notes sur papier et de débriefer à la fin du test, une fois la mission remplie (ou son échec constaté).

Cas pratique

C’est le moment de laisser les développeurs en parler 😉

Et les développeurs, ils en ont pensé quoi ?

Interviewés : Luc, Thomas, Florian, Benjamin, Marien.

Salut à tous ! Pour commencer, vous pourriez vous présenter rapidement ainsi que vos projets ?

Florian : Salut ! Ici Florian aka mrflos, développeur web du mouvement Colibris, une association d’éducation populaire qui inspire, relie et soutient des personnes qui se mobilisent pour la construction d’une société plus écologique et plus humaine. Afin d’outiller nos membres avec des logiciels et services libres en adéquation avec nos valeurs, nous avons rejoint le collectif des CHATONS et nous proposons la plateforme https://colibris-outilslibres.org à toutes et tous.

Je suis par ailleurs co-auteur et principal mainteneur de https://yeswiki.net , un wiki ouvert et simple, avec des possibilités de base de données avec des restitutions variées (trombinoscope, cartes, agenda…)

Thomas : Salut ! Je suis Thomas alias tcit, développeur web au sein de Framasoft, une association promouvant les logiciels libres et plus largement l’univers libre. Nous avons dernièrement lancé une campagne Contributopia qui vise notamment à concevoir autrement des outils numériques. En dehors d’être responsable d’une bonne partie des outils Framasoft, dont certains ont été créés ou largement améliorés, j’ai aussi été mainteneur des logiciels wallabag (un service de lecture différée) et Nextcloud (une alternative à Dropbox et Google Drive).

Benjamin : Hello ! Ici Benjamin (ou encore bnjbvr), ingénieur logiciel chez Mozilla sur la machine virtuelle JavaScript / WebAssembly qui tourne dans le célèbre Firefox. Sur mon temps libre, je suis un peu membre de Framasoft où j’essaie d’organiser des ateliers de contribution au logiciel libre ouverts à tou.te.s, au sens large, en essayant d’attirer des personnes qui n’y connaissent pas grand chose. Je développe également Kresus, une application web de gestion de finances personnelles libre et auto-hébergeable, pour pouvoir comprendre comment notre argent est dépensé, comme une alternative aux apps Bankin ou Linxo.

Marien : Salut, pour ma part je suis Marien (alias, hum… Marien), ingénieur dans une boite qui s’appelle Sogilis et où je fais beaucoup de choses, mais notamment du développement d’applications web sur mesure. Je suis aussi membre de Framasoft : j’y maintiens Framaboard et je passe un peu de temps à consigner tout ce qu’il se passe au sein de l’asso dans notre wiki. Je réfléchis aussi à comment décloisonner les développeurs du Libre des sujets techniques (cet atelier tombait donc à pic !). Enfin, je développe Lessy, un logiciel de gestion de temps et j’ai été le développeur principal de FreshRSS, un agrégateur d’actualités, qui est depuis passé dans les mains d’une communauté active.

Luc : もしもし! (oui, Luc se met au Japonais, il a sûrement écrit un truc très chouette mais on n’a rien pané — NDLR)

Moi c’est Luc, alias (frama)sky, adminSys de Framasoft, et développeur aussi. J’ai notamment écrit Lstu, Lutim, Lufi et Dolomon, qui sont utilisés chez Framasoft sous les noms Framalink, Framapic, Framadrop et Framaclic.

 

L’UX, ça te parlait avant l’atelier ? C’était quoi pour toi ?

Florian : Comme je ne suis pas un très bon développeur, je compense en essayant de piocher dans les gros sites, des idées d’interfaces efficaces. Je me suis vite rendu compte que cela allait au delà de l’interface, et que c’était la convivialité de l’outil et l’expérience dans sa globalité qui faisait qu’on l’adoptait.

Pour moi, l’expérience utilisateur est primordiale, car si le but est d’amener nos utilisateurs à contribuer, il faut leur faciliter la tâche, et la moindre expérience négative peut facilement démotiver. D’ailleurs assez souvent les utilisateurs ne reprochent pas le manque de fonctionnalités d’un logiciel libre par rapport à son concurrent non libre, mais le fait qu’il soit plus difficile à utiliser (ou moins ergonomique).

Thomas : De même, la prise en compte de l’aspect convivial lors de mes développements se résumait à piocher des bonnes idées ici et là, suivre quelques pistes d’amélioration pour que certains aspects soient plus accessibles et des actions plus faciles à réaliser. J’avais largement conscience des manques que j’avais sur ces points.

Benjamin : J’ai eu l’occasion de discuter avec des designers, notamment parce que l’équipe de Kresus désirait avoir un nouveau logo. Alors que je pensais qu’il allait s’agir simplement de choix esthétiques, nous nous sommes retrouvés à parler d’aspects de bien plus haut niveau, comme les émotions que l’on voulait transmettre, ou les principes que devait respecter l’application. Même si ça relève du design, ces aspects se transposent également très bien à l’UX, et cette discussion a été le point de départ d’une réflexion plus globale pour re-prioriser certaines fonctionnalités et certains manques de Kresus. Par ailleurs, certains retours de personnes expérimentées en UX design nous avaient bien résumés l’intérêt de l’UX : un élément d’interface ou une action peu claire ou compliquée, c’est une incompréhension ; et une incompréhension, c’est une question au mieux (donc du support à effectuer), un blocage au pire (donc un.e utilisateur.ice perdu.e). Ce discours m’a marqué et incité à me plonger encore plus dans le sujet.

Marien : J’ai la chance de travailler dans une boîte qui employait déjà une UX/UI designer lorsque je suis arrivé. Aujourd’hui j’ai deux autres supers collègues ergonomes et/ou UX designers avec qui je peux travailler et échanger (je recommande d’ailleurs leurs « ergogames » lors desquels j’ai appris et pu mettre des mots sur plein de concepts), j’étais donc déjà plutôt bien rodé avant cet atelier et persuadé des bienfaits de l’UX. Pour moi, toute l’importance de cette discipline est de remettre l’utilisateur·ice au centre des préoccupations du logiciel : on cherche avant tout à comprendre ses problèmes et ses besoins. Ça peut paraître idiot dit comme ça, mais bien souvent j’ai affaire à des utilisateurs qui expriment leurs problèmes à travers des solutions qu’ils ont eux-mêmes imaginés. Le problème c’est qu’ils ont toujours une connaissance limitée de ce qui peut se faire (et moi aussi !) La complexité consiste à faire abstraction de ces solutions pour essayer d’en imaginer une qui sera potentiellement mieux adaptée aux besoins exprimés bien souvent indirectement. C’est là tout le talent de l’UX designer. 🙂

Une autre chose que j’apprécie – et c’est assez contradictoire avec mon statut de développeur – c’est que ça nous fait redescendre de notre piédestal. Dans les projets de logiciels libres, le développeur est toujours celui qui imagine, décide et code ; ça ne fait pas de mal de se remettre en question parfois ! Et puis nous avons déjà suffisamment de responsabilités comme ça (« Code is Law » comme dirait l’autre), pas la peine de nous en rajouter.

Luc : Oui… et non. Oui, parce que je savais que ça existe, non parce que je n’avais pas le temps de me pencher dessus.

 

Est-ce que tu avais déjà appliqué ou envisagé d’appliquer des méthodes UX sur tes projets ? Est-ce que par exemple tu avais déjà fait des tests utilisateur·ices auparavant ?

Florian : Au sein des contributeurs YesWiki, certains avaient déjà fait des tests utilisateurs, mais moi-même, je n’avais pas eu l’occasion de tester. J’avais entendu parler d’une méthode rigolote, qui consiste à tester un site en étant complètement saoul pour voir si la navigation était facile ! Une version plus « sobriété heureuse » consisterait à juste plisser les yeux et voir si vous arrivez à naviguer sur votre site, ou sinon http://www.drunkuserexperience.com/?url=https%3A%2F%2Fframasoft.org .

Thomas : Il y a quelques mois je ne désirais rien de plus que des mockups tout faits que j’aurais juste à intégrer. Aujourd’hui j’ai compris qu’il est préférable d’avoir un processus d’accompagnement, de travail itératif en collaboration et en discutant avec quelqu’un ayant les compétences.

Les seuls tests utilisateurs que j’aie effectués dans le cadre de mon travail se résumaient à envoyer un aperçu quasiment achevé à des membres de l’association n’ayant pas ou peu de compétences techniques, mais je n’étais pas derrière eux pour obtenir d’autres retours que ceux qu’ils peuvent me faire eux-mêmes. En dehors de cela, zéro, nada.

Benjamin : Non, jamais, je partais donc d’une expérience totalement vierge.

Marien : Oui, mais c’est assez récent au final ! J’avais fait appel il y a un an à Marie-Cécile Paccard pour m’aider sur Lessy. L’expérience a été tout aussi déstabilisante qu’enrichissante : alors que je pensais qu’on parlerait de l’UX de l’application, on a parlé de beaucoup de choses en amont, notamment à quels problèmes je cherchais répondre et à qui je m’adressais. Au final, elle a appliqué les méthodes UX à l’idée du projet elle-même ! Pour ce qui est des tests utilisateurs, j’ai participé à une session mais en tant qu’utilisateur, je connaissais donc déjà le format mais pas l’angoisse de se faire « juger » son travail ! J’avais toutefois eu le sentiment que c’était un format lourd à mettre en place et j’ai été agréablement surpris de la manière dont ça s’est passé au Framacamp.

Luc : À chaque phase de tests des nouveaux services Framasoft, on avait des retours de la part des membres de l’asso, mais ça s’arrêtait là.

 

Qu’est-ce que tu as pensé des méthodes vues ? Une méthode favorite ?

Florian : Le panel des méthodes vues était très large et c’est difficile de donner une favorite, car elles sont complémentaires ! Comme elles sont toutes assez courtes, je recommanderais plutôt de les faire toutes pour avoir une idée globale. S’il fallait choisir, la méthode du test en 5 secondes est vraiment rapide à faire, l’expliquer et la faire ne prend pas plus de 5 minutes, douche comprise ! Après, les tests utilisateurs sont ceux qui amènent sans doute le plus de pistes concrètes d’évolution pour son projet car on voit de façon flagrante là où l’utilisateur a des difficultés.

Benjamin : Si l’on se concentre uniquement sur l’aspect UX, la méthode des 5 secondes me semble plus amusante qu’utile, parce qu’elle ne reflète pas le fait que les gens cherchent toujours un peu avant d’abandonner. Elle permet cependant de dégager un avis esthétique et une émotion de manière très pertinente, ce qui provoquera l’envie d’utiliser par la suite. Clairement, le test d’utilisation, effectué sur Kresus, a été le plus utile et le plus fructueux pour moi : malgré la frustration qui parfois s’installait, puisque j’avais envie de dire « mais non, c’est pas comme ça qu’il faut faire », ou encore de dire « tu as remarqué qu’il manquait telle fonctionnalité, tu es au moins la 100ème personne à me le dire », j’ai trouvé très intéressant le fait de tout garder pour moi, et de juste écouter les utilisateur.ice.s pour comprendre quels étaient leurs points bloquants et leurs interrogations.

Marien : Très clairement j’ai préféré les tests utilisateurs. Je rejoins pas mal Benjamin là-dessus, j’ai le sentiment que c’est ce qui a été le plus utile. Mais c’est aussi l’aspect humain que je trouve intéressant : cette posture tout d’abord d’écoute et d’observation silencieuse (ça empêche de tenter de se justifier !), puis l’échange qui suit après. Ça permet aussi aux différents protagonistes de se rencontrer et de mieux se comprendre. Toutefois, pour un logiciel Libre ça peut être compliqué à mettre en place par sa nature décentralisée. L’AttrakDiff est peut-être alors plus adapté tout en se rapprochant de ce que peut apporter les tests utilisateurs d’un point de vue retours UX. J’imagine assez bien utiliser la méthode des 5 secondes « à l’arrache » lors de différents évènements. Concernant les courbes d’évaluation, je ne connaissais pas du tout et j’ai trouvé le concept super intéressant même si j’imagine un peu moins quoi faire des résultats.

Thomas : Je rejoins les deux commentaires précédents pour dire que j’ai probablement considéré le test utilisateur comme le plus productif du point de vue d’un développeur. Cela permet de découvrir des utilisations complètement à l’opposé de ce que l’on peut imaginer, et ainsi sortir de sa bulle de filtre concernant la vision que l’on a de son projet. J’aime aussi également bien le test des 5 secondes, mais je l’ai trouvé particulièrement efficace surtout lorsqu’on imagine un utilisateur arriver sur un site web sans à priori dessus, pas forcément quelqu’un de très motivé voir obligé d’utiliser une application.

Luc : Tout comme les autres, le test utilisateur est sans doute le plus intéressant pour les développeurs. On a ainsi un retour rapide mais surtout concret sur les points de friction.

 

C’est quoi le ressenti pendant et après les tests utilisateur·ices, quand on observe un·e utilisateur·ice manipuler et faire des retours sur son projet adoré ?

Florian : Mon cas est particulier, car on testait des visuels fait par Kristof, le graphiste des Colibris, pour le test des 5 secondes, donc j’ai moins pris pour moi les retours. Par contre j’ai été testeur pour Luc et son projet dolomon.org, et c’était bien drôle, je l’ai vu rougir quand je n’ai pas cliqué sur le lien « comment ça marche » et directement m’empêtrer dans les fonctionnalités compliquées, mais je crois que je me suis comporté comme un utilisateur lambda ! 😉

Benjamin (en continu depuis la question précédente) : C’est extrêmement utile comme exercice, parce que chaque élément remarqué devient utilement concret et peut se transformer en un « ticket » ou un élément partiel de ticket, tout du moins. C’était aussi marrant de voir, lors du débriefing, chacun exposer les *problèmes* auxquels iels étaient confrontés, et d’y aller de sa *solution* pour les résoudre, sans connaître l’ensemble des contraintes du projet. 🙂

En tant que mainteneur d’un projet, cela m’a permis de rester humble auprès du travail restant à accomplir, et ne m’a pas atteint émotionnellement ou attristé, parce que je considère que tout est toujours améliorable, et la finalité commune (de cellui qui teste ou cellui qui observe) est d’améliorer le logiciel dans son ensemble, pour le rendre plus utilisable, donc plus utilisé. 🙂

En dehors de la sphère propre au logiciel Kresus, je me sens plus légitime et j’ai aussi beaucoup plus confiance en ma capacité à mener et assister à des tests utilisateurs, ce qui me sera utile lors de nos célèbres Contrib’Ateliers .

Marien : Le plus compliqué était sans doute de rester silencieux ! D’ailleurs j’ai posé une ou deux questions au début pour essayer de comprendre le ressenti de l’utilisatrice (mais j’ai vite arrêté parce que je sentais que ça pouvait influer sur son utilisation). Il y a une forme de frustration qui se développe au fur et à mesure que la personne observée cherche mais ne trouve pas (pour les deux tests effectués j’ai eu envie de dire « Tu n’as pas besoin de rechercher l’icône de flux RSS sur le site, l’outil le détecte pour toi ! ») Une chose amusante en revanche, c’était de se sentir par moment tout aussi perdu que la personne qui testait (« Bah tiens, pourquoi ça réagit comme ça ? », « Oh un bug… ah non c’est vrai, c’est le comportement « attendu » »). Au final on n’est pas seulement observateur de l’utilisateur·ice, mais aussi de sa propre application ! En sortie de cette expérience, j’ai été rassuré sur la facilité de mise en place, ça m’a vraiment réconcilié avec cette méthode UX. Hâte de réitérer l’expérience !

Luc : C’est dur pour moi de me taire… et de voir que les utilisateurs ne prennent pas le temps de lire les explications qu’on s’est fait c… suer à écrire !

 

Suite à l’atelier, est-ce que tu penses que tu vas essayer de mettre en place de l’UX ? Si on te trouve un·e UX Designer, tu l’accueilles les bras ouverts ?

Florian : Oui, bien sûr, c’est un retour précieux, et une science à part entière ! Vu le peu de moyens humains derrière un projet libre, on se retrouve souvent à être en même temps le graphiste, l’UX designer, le développeur et le chargé de comm. de ce projet libre, et souvent quand on touche à trop de choses simultanément, on ne fait pas tout bien. J’ai très envie d’approfondir le sujet, si possible accompagné, mais j’attends aussi de voir comment en tant que développeur, implémenter les améliorations d’UX, car les choses les plus simples ne sont pas toujours les plus faciles à coder ! Donc vive la complémentarité mais en ayant la curiosité de s’intéresser à ce que l’UX Designer apporte et réciproquement, histoire de s’enrichir entre designer et développeur et d’être réaliste sur ce que l’on peut faire ensemble !

Benjamin : Absolument ! Au titre de mon projet Kresus, je vais sûrement réitérer l’expérience, et nous serions ravis d’accueillir un.e UX designer pour nous aider à assurer un suivi de l’amélioration de l’UX dans le projet. Nous allons d’ailleurs revoir nos méthodes de contribution pour simplifier la découverte et la participation à ce projet. Par ailleurs, je vais très probablement réutiliser les méthodes vues ici lors des Contrib’Ateliers, pour pouvoir tester et faire tester d’autres projets qui ont bien besoin d’aide, en espérant que cela mène à des actions concrètes et un suivi de la part des auteur.ice.s.

Marien : Je ne vois pas trop comment répondre négativement à cette question après les réponses que j’ai données jusqu’ici. ^^

Oui, évidemment que j’en accueillerais un ou une ! Mais j’aimerais aussi réfléchir à comment faciliter une telle collaboration. Aujourd’hui les outils que nous avons à notre disposition ne sont pas adaptés (je ne vise absolument pas GitHub ou plus généralement les forges logicielles, ce serait mal me connaître). Et si, justement, on appliquait les méthodes UX pour réfléchir à un tel outil ? 😀

Thomas : De même, c’est évident qu’il faut que nous impliquions davantage des gens comme des UX designers prêts à participer dans nos projets libres. Et pour accueillir des gens qui ne sont pas développeurs, ce n’est pas uniquement une question de réfléchir à un processus pour l’entrée de nouveaux contributeurs, c’est peut-être penser dès le début à faire en sorte que les décideurs et responsables de projets ne soient pas uniquement des développeurs, que ces derniers ne soient pas toujours au centre du projet. C’est loin d’être facile dans le milieu du logiciel libre, mais je veux y croire. 🙂

Luc : Non, je souhaite continuer à faire des logiciels inaccessibles. Tout le monde sait bien que les logiciels tournent bien mieux sans utilisateurs pour déclencher des bugs ou poser des questions. 😛

 

Et la tradition Framasoft : un dernier mot pour la fin ?

Florian : Merci Framasoft de décloisonner le libre et d’ouvrir vers de nouveaux horizons avec des outils qui ont du sens et des valeurs et qui pourraient grâce à des apports dans des domaines comme l’UX, de plus en plus répondre aux besoins des usagers ! J’en profite aussi pour inviter des animateurs de réseaux, les techniciens, les citoyens engagés, et toutes les personnes de bonne volonté de venir participer au projet Contributopia, qui pourrait être un beau levier de changement sociétal et de convergence !

Benjamin : Merci Framasoft pour ce Framacamp, et merci beaucoup Maïtané pour nous avoir présenté et ouvert les yeux sur l’UX, dans la joie et la bonne humeur, sans m’avoir fait ressentir ce tristement classique blocage entre les développeur.euse.s et les designers. J’invite tout le monde à s’intéresser également à ces méthodes, ne serait-ce que pour en comprendre les enjeux, qui dépassent largement la simple facilité d’utilisation et l’aspect esthétique des choses. :3

Marien : Au final, comme dans tout projet, l’important c’est de se parler et de s’écouter. Ce Framacamp a été une formidable occasion de faire cela dans une ambiance détendue. Je suis vraiment ravi de pouvoir apporter ma patte au projet Contributopia qui se propose justement d’encourager et défendre tout ça. Je suis persuadé que nous sommes sur la bonne route (mais qu’est-ce qu’elle est longue !). Et merci aussi à Maïtané de nous avoir proposé cet atelier qui m’a permis (enfin) de mettre en pratique des choses qui traînaient dans ma tête depuis des mois.

Thomas : Merci aux membres de Framasoft et à tous les contributeurs pour leur bonne volonté toujours impressionnante. Merci à ceux qui animent des ateliers qui permettent de faire des énormes pas en avant à chaque fois. J’ai hâte de voir ce qu’on va tous faire ensemble !

Luc : Merci à tous ceux qui vont mettre en place des ateliers UX lors des prochains contrib’ateliers. 😁

À leur tour, les auteur·ices de cet article remercient chaleureusement Florian, Thomas, Benjamin, Marien et Luc pour le temps qu’ils ont bien voulu nous accorder pour répondre à nos questions. Merci également à Carine Lallemand pour nous avoir autorisé·es à utiliser les images d’illustration de l’AttrakDiff et des courbes d’évaluation UX.

Que vous soyez UX Designer (professionnel ou amateur) ou simple utilisateur·rice qui veut contribuer au logiciel libre et au libre, n’hésitez pas à venir à notre rencontre, soit sur Framacolibri ou lors d’un des Contrib’ateliers.  ;-).

 

 

Pour aller plus loin

  • Lallemand, Carine. Paris Web 2015. Atelier Évaluer l’UX : des méthodes simples mais efficaces !

Paris Web 2015 Atelier « Evaluer l’UX : des méthodes simples mais efficaces ! » from Carine Lallemand

 




Contribuer à un logiciel libre dans une formation en école d’ingénieur

Des étudiants de l’Université de Technologie de Compiègne effectuent, dans le cadre de leur cursus, des Travaux de Laboratoire consistant à avancer sur des tickets du projet Framadate (qui n’en manque pas), avec le soutien de leur enseignant Stéphane Crozat (dont on vous reparlera) et du CHATONS local Picasoft. Leurs travaux sont documentés dans un wiki et leur avancement dans des pads.

De la belle contribution utile !

Pour commencer, une petite présentation s’impose : je m’appelle Justine et je suis en première année de formation ingénieur en informatique à l’UTC (Université de Technologie de Compiègne). Lors de ce semestre, c’est-à-dire lors des quatre derniers mois, et dans le cadre de ma formation (ce travail, après évaluation, pourra m’apporter 5 crédits ECTS), j’ai eu l’occasion de contribuer au logiciel libre Framadate. Cet article se veut être un bilan de mon expérience.

 

Contribuer à un logiciel libre, était-ce différent d’un projet « classique » ?

À l’UTC, les étudiants sont évalués selon des barèmes différents d’une matière à l’autre. En informatique, l’évaluation comprend souvent un projet (qui ne correspond pas souvent à plus de 20% de la note finale). Ce projet a des objectifs largement pertinents, comme vérifier sur un cas pratique que les étudiants ont assimilé la théorie qui leur a été enseignée. Cependant, j’ai souvent éprouvé une certaine frustration vis-à-vis  de ces projets. En effet, une fois rendu, évalué et donc noté, le projet tombe dans l’oubli : pas d’utilisation réelle, pas d’amélioration, une sorte de produit déjà mort à sa sortie. Ainsi, l’idée de travailler sur un logiciel  libre, avec des utilisateurs bien réels derrière, m’a semblé extrêmement pertinente et bien différente des projets que j’avais déjà pu mener.

Est ce que ces différences ont entraîné des difficultés ?

Les premières difficultés rencontrées ont été celles posées par l’installation et la prise en main de l’environnement de travail, proposé par les suiveurs. Alors que la plupart du temps, pour mener à bien les projets classiques, les installations des environnements sont déjà faites sur les machines de l’UTC, cela n’était pas le cas cette fois. Composé de nombreux outils (principalement Docker et Git au sein de Linux), l’installation de notre environnement a été relativement lourde et laborieuse. Une fois installé, l’environnement est au premier abord difficile à prendre en main : de nombreuses lignes sont à exécuter dans l’interpréteur de commandes avant de pouvoir tester le code.

Mais les difficultés les plus compliquées à surmonter ont été celles posées par le projet en lui-même. D’abord parce que les langages utilisés (SQL, PHP orienté objet, Javascript, HTML via le moteur de templates Smarty…) ne m’étaient pas ou peu connus. Ensuite, et surtout, parce qu’il m’a paru très compliqué de m’insérer dans un projet déjà bien développé (dans un projet « classique » à l’UTC, on part de rien, on développe tout), projet dont l’architecture n’est pas (ou très peu) documentée. Sa compréhension a donc nécessité beaucoup de temps et d’efforts, j’y reviendrai.

Comment s’est organisée ta contribution ?

Cette contribution a été organisée selon une méthode de type agile : le travail est découpé en itérations de six heures chacune, une itération par semaine. Le semestre a ainsi été rythmé par des réunions de suivi hebdomadaires avec les suiveurs, Stéphane Crozat et Andrés Maldonado, chargés d’accompagner et d’évaluer le travail. Sur chaque itération, nous déterminions donc ensemble l’objectif à atteindre pour la semaine suivante, et je déterminais seule l’articulation de mon travail (combien d’heures je devais passer à réaliser telle tâche). La contribution s’est articulée en deux volets : un volet de développement (qui consistait en la résolution de trois issues ouvertes sur le projet) et un volet de documentation (via le wiki de l’association Picasoft).

Concrètement, qu’as-tu apporté à Framadate ?

Comme évoqué plus haut, l’architecture du projet n’était que très peu documentée. Ainsi, afin de travailler efficacement sur le projet, j’ai préféré commencer par passer plusieurs heures (concrètement une vingtaine) à explorer le projet et documenter au maximum ce que j’en comprenais (les classes implémentées, leur articulation au sein du projet…). Un travail étudiant comme celui-ci est aussi l’occasion d’apprendre à formaliser et documenter, mon travail est disponible ici.

Ce n’est que dans un second temps que j’ai réellement commencé mon travail de résolution d’issues, et donc de développement et de documentation du travail réalisé. J’ai préféré travailler ces deux volets en parallèle, afin de restituer le travail réalisé lorsque tout était encore frais dans mon esprit. J’ai ainsi pu travailler sur trois issues :

Issue #38 : collecter les adresses e-mail des sondés
L’idée est de permettre à l’administrateur de choisir de collecter (ou non) les adresses e-mail des sondés. Si l’administrateur choisit la collecte, alors la saisie d’une adresse de courriel valide (respectant le format e-mail) est obligatoire pour voter. La collecte s’accompagne d’une fonctionnalité permettant à l’administrateur de récupérer efficacement l’ensemble des adresses des personnes sondées.

A la création d’un sondage, l’administrateur choisit s’il collecte ou non les adresses emails des sondés.

 

Un avertissement informe que, dans le cas où les votes sont modifiables par tous, n’importe qui ayant accès au sondage peut récupérer les adresses emails des sondés.

 

Pour voter, lorsque la collecte des adresses emails est active, une adresse email valide doit être renseignée. L’administrateur peut récupérer la liste des adresses emails des sondés grâce aux boutons enveloppe situés au dessus de chaque colonne. Si la collecte est active et que quiconque peut modifier tous les votes, un avertissement informe que n’importe qui peut accéder aux adresses emails des sondés.

 

En cliquant sur un bouton enveloppe, l’administrateur récupère les adresses emails des sondés triées selon leur choix (‘oui’, ‘si besoin’ ou ‘non’).

 

Issue #324 (et #61) : Amélioration de l’option de collecte des adresses e-mail des personnes sondées. L’idée était d’améliorer le travail réalisé précédemment en passant la collecte des adresses de courriel sous quatre options différentes :

  • option 1 : la collecte est désactivée ;
  • option 2 : la collecte est activée ;
  • option 3 : la collecte est activée et la saisie est obligatoire ;

option 4 : la collecte est activée, la saisie est obligatoire et le vote doit être confirmé par un clic sur le lien envoyé dans un mail à l’adresse renseignée (cette dernière option n’a pas été implémentée car le service d’envoi d’e-mail est inutilisable au sein de l’installation).

A la création d’un sondage, l’administrateur choisit une des quatre options pour son sondage. De même que précédemment, un avertissement informe si les adresses emails des sondés ne sont pas protégées.

 

Issue #208 : permettre la finalisation d’un sondage par l’administrateur
L’idée était d’ajouter une fonctionnalité pour l’administrateur de clôture de sondage et de lui permettre :

  • de sélectionner le choix retenu ;
  • de justifier son choix.

Dans les informations du sondage, l’administrateur et l’utilisateur sait si le sondage est encore ouvert ou s’il est fermé (ici, il est encore ouvert). L’administrateur peut fermer le sondage en cliquant sur le bouton.

 

Une fois le sondage fermé, l’administrateur peut sélectionner le choix qu’il retient grâce au bouton au dessus de chaque colonne. La valeur de ce choix est visible dans les informations du sondage, côté administrateur et côté utilisateur.

Une fois un choix sélectionné, l’administrateur peut justifier son choix. La valeur de cette explication est visible dans les informations du sondage, côté administrateur et côté utilisateur.

Chacune de ces résolutions d’issues a fait l’objet d’une merge-request. C’est un processus itératif très intéressant à découvrir au sein duquel on peut interagir avec les développeurs logiciel et web de Framasoft qui vont vérifier le travail proposé et en demander des corrections.

Tout au long de mon travail, j’ai pu ainsi interagir avec différents interlocuteurs : les suiveurs bien sûr, Stéphane Crozat et Andrés Maldonado, mais aussi Thomas Citharel, développeur logiciel web chez Framasoft, et Kyâne Pichou, diplômé de l’UTC. Je tiens à remercier tous ces interlocuteurs pour leur soutien et leurs conseils, je pense qu’il est indispensable d’être bien accompagnés dans ce processus de contribution afin qu’il soit efficace et utile à tous.

Finalement, quels sont les apports au sein de ta formation ?

Contribuer à Framadate m’a d’abord permis de gagner en compétences d’utilisation des outils utilisés (Docker, Git, Linux) et en développement web : interface, base de données,…. Mais cette contribution m’a surtout fait gagner énormément d’indépendance et d’autonomie vis-à-vis d’un projet déjà existant et bien développé, ce qui est très formateur et pertinent en amont de mon futur stage (six mois en entreprise à partir de septembre).

Que faudrait-il retenir de cet article ?

Contribuer à un logiciel libre au sein de la formation en école d’ingénieur constitue une expérience très pertinente pour compléter le profil théorique et « scolaire » d’un étudiant. Cette expérience permet de faire face à de nouvelles difficultés, et ainsi développer de toutes nouvelles aptitudes.

 

En savoir plus :

ECTS : European Credits Transfer System, calculés en fonction de la charge de travail de l’étudiant , ils permettent l’obtention des diplômes français (et européens).

Picasoft est le CHATON créé par les étudiants de l’UTC.




Ce qui nous pousse au Libre

Si certains logiciels libres sont réputés à la fois pour leur efficacité et leur esthétique fonctionnelle (qu’on nommera design, parce que c’est ainsi), il faut reconnaître qu’ils ne font pas la majorité.

Certains designers aimeraient apporter leur pierre à l’édifice libriste, et rendre plus attractifs et fonctionnels les logiciels libres, mais la route semble encore bien longue comme l’a récemment constaté Maiwann. Le dialogue entre développeurs de logiciels libre et designers semble cependant s’amorcer sous les meilleurs augures, d’abord en identifiant clairement les besoins mais aussi en proposant des solutions d’interactions. Dans ce billet, Marien Fressinaud apporte une réponse de développeur et identifie, à son tour, un espace de convergence. Cet article a été initialement publié sur son blog sous licence « CC BY ».

Marien, développeur et membre de Framasoft.

Il y a quelques jours, Maiwann proposait dans un article de réconcilier designers et logiciels libres. L’article ne manque pas d’intérêt, ne serait-ce que parce qu’il identifie les freins à la collaboration des designers au libre et suggère des actions concrètes pour y remédier.

Bien que je partage bon nombre des constats, je souhaitais le « compléter », cette fois en adoptant le point de vue du développeur que je suis. En effet, il est un sujet que Maiwann n’aborde quasiment pas : pourquoi faire du logiciel libre ? Pour ma part, j’aurais en effet aimé mieux comprendre ce qui motive des designers à vouloir contribuer au Libre. En guise d’effet miroir, j’essaie donc dans cet article d’envisager les raisons qui peuvent inciter un développeur à le faire, sans prétendre être exhaustif. Cette mise en perspective repose sur mes expériences personnelles concernant FreshRSS, Lessy, les actions menées au nom de Framasoft ou encore à travers les écrits que j’ai pu lire à droite à gauche.

Apprentissage

Dans l’article de Maiwann, la seule référence à une potentielle motivation se trouve au détour d’un paragraphe :

Lors de nos études, […] alors que nous cherchons à nous entraîner, sur notre temps libre ou pour des projets de fin d’année, nous nous plaignons de ne connaître aucun développeur avec qui co-créer des sites ou logiciels.

Voilà une raison qui devrait parler à bon nombre d’étudiants et d’étudiantes ! Appliquer ce que l’on a pu apprendre en cours et donc, par extension, apprendre par la pratique est souvent moteur chez les développeurs. J’ai moi-même développé un certain nombre de programmes avec cette simple motivation. Par exemple, Minz fut ma tentative de comprendre le fonctionnement interne des frameworks web. FreshRSS a été l’occasion de travailler véritablement en communauté, et donc en équipe collaborant à distance et de façon asynchrone. Sur Lessy, j’ai pu consolider tout un paquet de connaissances que j’ai ensuite pu proposer et appliquer au boulot. Le logiciel libre est une formidable source d’apprentissage que je recommande fortement à toutes et tous.

Cela étant dit, considérer l’apprentissage comme seul moteur dans le développement d’un logiciel libre est bien entendu extrêmement réducteur et j’aurais tendance à dire que ce n’est pas la raison majeure (bien qu’il s’agisse probablement de la porte d’entrée principale pour bon nombre d’entre nous). Cherchons donc ailleurs d’autres raisons qui nous poussent, nous développeurs et développeuses, à produire du logiciel libre.

Plaisir, apprentissage et logiciel libre : le Serious Gaming (et Framinetest) en sont un bon exemple.

Plaisir

Dans le prologue du bouquin L’Éthique hacker, Linus Torvalds explique les motivations des hackers derrière le système d’exploitation Linux :

La raison pour laquelle les hackers derrière Linux se lancent dans quelque chose, c’est qu’ils trouvent ça très intéressant et qu’ils veulent le partager avec d’autres. Tout d’un coup, vous avez le plaisir parce que vous faites quelque chose d’intéressant et vous avez aussi le pendant social.

Il nous dit plusieurs choses ici. Tout d’abord, le développement d’un tel système relève avant tout du plaisir. Et il est vrai qu’on peut se demander ce qui pousse des milliers de développeurs à partager leurs savoirs et leur temps, généralement de façon gratuite, si ce n’est le plaisir de le faire ? D’ailleurs Pekka Himanen (l’auteur du bouquin) cite un peu plus loin Éric Raymond, à l’origine de la popularisation du terme « open source » (j’aurai l’occasion de revenir sur ce terme plus tard) :

La conception de logiciel et sa mise en œuvre devraient être un art jubilatoire, et une sorte de jeu haut de gamme. Si cette attitude te paraît absurde ou quelque peu embarrassante, arrête et réfléchis un peu. Demande-toi ce que tu as pu oublier. Pourquoi développes-tu un logiciel au lieu de faire autre chose pour gagner de l’argent ou passer le temps ?

On y retrouve la notion de plaisir à travers le « jeu haut de gamme ». Je prends souvent l’exemple du Sudoku ou de la grille de mots-croisés : il n’y a, à priori, aucune raison de remplir ces cases de chiffres ou de lettres, si ce n’est le plaisir de résoudre un problème, parfois complexe. Je trouve personnellement que le développement de logiciel peut amener à un état de satisfaction similaire lorsqu’on se trouve face à un problème et qu’on arrive finalement à le résoudre après plusieurs heures jours semaines de recherche.

D’un point de vue personnel, j’ai toujours été attiré par les domaines de « création ». J’ai immédiatement accroché au développement lorsque j’ai découvert que créer un site web était aussi simple que créer un fichier texte avec quelques mots dedans. Les balises HTML ? – Un simple jeu de Lego®. Les CSS ? – Quelques directives de base à connaître et on arrive rapidement à quelque chose de totalement différent. Un serveur web ? – Un ordinateur avec un logiciel spécifique qui tourne dessus. Un bug ? – Une « chasse » durant laquelle on déroule le programme qui nous semblait si logique au moment de l’écrire (mais qui l’est maintenant beaucoup moins !). Pour moi, la beauté de l’informatique réside dans sa simplicité et sa logique : il y a un véritable plaisir à comprendre comment toutes ces petites boîtes s’agencent entre elles et que tout devient plus clair.

L’espace Logiciels Libres, Hackers, Fablab de la fête de l’Huma 2016.

Partage

Si l’on s’en tient aux notions d’apprentissage et de plaisir, il n’y a rien qui distingue le logiciel libre du logiciel propriétaire. Vous pouvez très bien apprendre et éprouver du plaisir en développant du code fermé. Il nous faut revenir à la citation de Torvalds pour commencer à percevoir ce qui les différencie :

[…] ils veulent le partager avec d’autres.

Le partage : on a là une valeur fondamentale du logiciel libre qui ne trouve pas véritablement son pendant du côté du logiciel propriétaire. Bien que j’aie plus de mal à identifier clairement ce qui peut motiver l’être humain à partager ses savoirs, c’est quelque chose que je ressens effectivement. Cet aspect coopératif — Torvalds parle d’un « pendant social » — peut créer ou renforcer des liens avec d’autres personnes ce qui rend cette activité profondément humaine.

Partager, c’est donc transmettre. Transmettre à une communauté, donner les clés pour que celle-ci soit indépendante. Partager ses savoirs qui permettront peut-être à d’autres de bâtir autre chose par-dessus. Cela permet aussi de créer du lien humain, rencontrer des personnes et ouvrir ses perspectives en créant son propre réseau. C’est aussi s’offrir un coin de canapé quand on voyage. Je me suis rendu compte assez récemment de ce que m’offrait aujourd’hui cette décision en IUT de partager les petits programmes que je pouvais développer sur mon temps libre. La liberté n’est pas que celle du code.

Il y a certainement une forme de fierté à avoir exploré un domaine le premier, ou développé une application que d’autres vont utiliser (« Quoi ? Ce que j’ai fabriqué de mes propres mains t’est aussi utile ? »). Si cette fierté est par essence un peu narcissique (je suis toujours un peu pénible lorsque je suis cité chez NextInpact ou chez Korben 😇), elle est aussi bénéfique car elle encourage à rendre son travail public et donc… partager encore.

Loin du cliché des hackers à capuche, l’édition 2018 du Toulouse HackerSpace Factory utilise Langue des Signes et police Open-Dyslexie dans son imagerie.

Éthique

On retrouve aussi cette notion de partage dans les écrits de Richard Stallman lorsqu’il nous parle des quatre libertés du logiciel :

Elles sont essentielles, pas uniquement pour les enjeux individuels des utilisateurs, mais parce qu’elles favorisent le partage et la coopération qui fondent la solidarité sociale.

Ces mots, pris du point de vue de Stallman, sont bien évidemment à interpréter sous la dimension éthique (et donc politique) du logiciel libre, ce qui n’est pas forcément le cas de Torvalds (je ne saurais néanmoins l’affirmer). Puisque Stallman est à l’origine du mouvement du logiciel libre, on ne peut évidemment pas enlever l’éthique de son équation ou alors vous obtenez de l’open source (comme il l’explique dans l’article cité plus haut). On peut toutefois raisonnablement penser que les partisans du logiciel libre sont moins nombreux que ceux de l’open source, ce que j’explique par une peur ou un désintérêt envers cet objet politisé.

Je trouve toutefois dommage de ne pas plus s’y intéresser. En effet, la dimension éthique aide à répondre à une question que beaucoup de personnes peuvent se poser : « ce que je fais au quotidien a-t-il du sens ? ». Stallman y répond par la défense et le respect des utilisateurs et utilisatrices :

Le mouvement du logiciel libre fait campagne pour la liberté des utilisateurs de l’informatique depuis 1983.

Ou encore :

Pour qu’on puisse dire d’un logiciel qu’il sert ses utilisateurs, il doit respecter leur liberté. Que dire s’il est conçu pour les enchaîner ?

Si je souhaitais conclure par cet argument, c’est parce qu’il aide à boucler la boucle avec l’article de Maiwann. En effet, en tant qu’UX designer, elle va avoir à cœur de répondre aux besoins de ses utilisateurs et donc d’imaginer des mécanismes pour rendre l’outil le plus utilisable et accessible possible. Aujourd’hui il me semble percevoir dans cette communauté un mouvement de prise de conscience que ces mécanismes doivent respecter (on y revient !) les personnes utilisant le logiciel. Cela est superbement bien illustré par la vidéo « Temps de cerveau disponible » (de la série « (Tr)oppressé » que je recommande vivement) dans laquelle un ancien employé de Google, expert en éthique, témoigne :

Le but est de capter et d’exploiter au maximum l’attention.

Il l’illustre ensuite par le lancement automatique de l’épisode suivant sur Netflix et par le défilement infini sur Facebook ou Twitter (incitant de ce fait à parcourir son fil d’actualité dans son ensemble) ; ces petits riens qui font que nous revenons sans cesse à ces applications et que nous en devenons dépendant⋅e⋅s alors qu’elles n’ont d’intérêt que de nous divertir.

L’un des problèmes que j’identifie aujourd’hui est que le logiciel libre copie beaucoup (trop) ce qui se fait dans le propriétaire, et en particulier chez GAFAM et consorts… jusque dans leurs mécanismes nocifs. On peut ici reprendre l’exemple du mécanisme de défilement infini que l’on retrouve chez Mastodon ou Diaspora (et même sur FreshRSS !). Une certaine forme de dépendance peut donc s’installer au sein même de logiciels libres.

Convergence des buts ?

Les designers peuvent aujourd’hui nous aider, développeurs et développeuses, à repenser l’éthique de nos logiciels en replaçant les usages au centre de nos préoccupations et en imaginant et proposant des mécanismes permettant « d’endiguer » ce flux permanent d’informations qu’il nous faut ingurgiter.

Elles et ils peuvent aussi nous aider à atteindre véritablement nos utilisateurs et utilisatrices en rendant nos outils utilisables et… utilisés. Car un logiciel non utilisable peut-il véritablement être considéré comme Libre ? Je ne peux m’empêcher de faire ici le parallèle avec l’association Liberté 0 qui a pour objet de « sensibiliser et de promouvoir le numérique libre et accessible à toutes et tous ». Dans leur charte, il est explicité :

Les membres du groupe « Liberté 0 » considèrent que la liberté d’exécuter un programme n’a de sens que si celui-ci est utilisable effectivement.

L’association est donc dans cette même démarche de promouvoir l’« utilisabilité » des logiciels, au même titre que les UX designers (mais sous le prisme de l’accessibilité).

N’y aurait-il pas ici une convergence des buts ? N’existe-t-il pas un lieu où nous pourrions nous regrouper tous ensemble pour imaginer des outils autres que ceux issus du « capitalisme de surveillance » ?


Merci à Maiwann pour sa relecture attentive !




Julia Reda, eurodéputée du Parti Pirate, lance un appel

Le projet de réforme du droit d’auteur provoque une forte inquiétude au sein des communautés de développeurs et développeuses de logiciels libres. Que restera-t-il de leur liberté de partager et modifier si obligation est faite aux forges logicielles de mettre en place des filtres de contenus ? L’eurodéputée Julia Reda nous indique les façons dont nous pouvons tous agir, dès maintenant.

 

« Les machines à censurer arrivent : il est temps que la communauté du logiciel libre prenne conscience de son impact politique »

 

Source : article rédigé par l’eurodéputée Julia Reda et publié sur son site le 6 avril 2018

Traduction initialement publiée par l’April : Guestr, Alain Mille, etienne, mmu_man, tierce, Vanecx, mo, MicroCheapFx, freepoet, yannicka, Fred.

Le développement du logiciel libre tel que nous le connaissons est menacé par les projets de réforme du droit d’auteur de l’Union européenne.

La bataille continue autour de la proposition de réforme du droit d’auteur dans l’UE, se concentrant autour du projet de filtrer les contenus au moment de leur téléversement (en anglais). En résumé, on demanderait aux plateformes en ligne de contrôler les contenus chargés par leurs utilisateurs et utilisatrices afin de tenter de prévenir les violations du droit d’auteur par des filtres automatiques. Puisque la plupart des communications en ligne consistent en un dépôt de fichiers sur différentes plateformes, de telles « machines à censurer » auraient de larges conséquences, y compris pour les dépôts de logiciels libres et open source.

Sur ces plateformes, des développeurs et développeuses du monde entier travaillent de concert sur des projets de logiciels que quiconque peut librement utiliser et adapter. À coup sûr, ces filtres automatiques feraient état de nombreux faux-positifs. La suppression automatique de contenus signifierait que les personnes ayant contribué seraient présumées coupables jusqu’à prouver leur innocence : des contributions légitimes se verraient bloquées.

Les récentes levées de boucliers à ce sujet au sein de la communauté du logiciel libre/open-source commencent à porter leurs fruits : nos préoccupations sont en train d’attirer l’attention des porteurs de lois. Malheureusement cependant, la plupart comprennent mal les enjeux et tirent de mauvaises conclusions. Maintenant que nous savons quelle est la force de la voix de la communauté, il est d’autant plus important de continuer à la faire entendre !

Pourquoi cela ?

Le point de départ de cette législation a été une bataille entre de grosses entreprises, l’industrie musicale et YouTube, à propos d’argent. L’industrie musicale s’est plainte de moins percevoir chaque fois qu’un morceau de leur catalogue est joué sur une plateforme vidéo comme YouTube que lorsqu’il est diffusé sur des services d’abonnement comme Spotify, qualifiant la différence de « manque-à-gagner ». Elle s’est alors lancée, avec succès, dans une campagne de lobbying : la loi sur le filtrage des contenus vise principalement à lui donner un atout afin de demander plus d’argent à Google au moment des négociations. Pendant ce temps, toutes les autres plateformes se retrouvent au milieu de cette bagarre, y compris les communautés de partage de code.

Le lobbying a ancré dans l’esprit de nombreux législateurs la fausse idée que les plateformes d’hébergement à but lucratif exploitent nécessairement les créateurs et créatrices.

Partage de code

Il y a cependant beaucoup d’exemples où il existe une relation symbiotique entre la plateforme et les créateurs et créatrices. Les développeurs et développeuses utilisent et versent volontairement dans les dépôts logiciels parce que les plateformes ajoutent de la valeur. GitHub est une société à but lucratif qui soutient des projets sans but lucratif – elle finance l’hébergement gratuit de projets libres et open source en facturant l’utilisation commerciale des services du site. Ainsi, des travaux libres et open source seront affectés par une loi destinée à réguler un différend entre quelques grandes sociétés.

Dans un récent billet (en anglais), GitHub a tiré la sonnette d’alarme, indiquant trois raisons pour lesquelles le filtrage automatique des contenus constitue une terrible attaque contre les forges logicielles :

  1. la loi impose que le code soit filtré parce qu’il est soumis au droit d’auteur – mais de nombreux développeurs et développeuses souhaitent que leur code source soit partagé sous une licence libre et open source ;
  2. le risque de faux positifs est très élevé parce que les différentes parties d’un logiciel peuvent être soumises à des licences différentes, ce qui est très difficile à traiter de manière automatisée ;
  3. le fait de supprimer automatiquement un code suspecté de porter atteinte au droit d’auteur peut avoir des conséquences désastreuses pour les développeurs et développeuses de logiciels qui s’appuient sur des ressources communes risquant de disparaître à tout moment.

Les inquiétudes commencent à être entendues

Dans sa dernière proposition, le Conseil de l’Union européenne cherche à exclure « les plateformes de développement open source à but non lucratif » de l’obligation de filtrer les contenus chargés par les utilisateurs et utilisatrices. Cet amendement est la conséquence directe de la levée de boucliers par la communauté FLOSS. Cependant, cette exception ne couvre pas les plateformes à but lucratif comme GitHub et bien d’autres, même si une partie seulement de leur activité est à but lucratif.

Plutôt que de remettre en cause le principe de base de la loi, les politiciens essayent d’étouffer les critiques en proposant de plus en plus d’exceptions à celles et ceux qui peuvent démontrer de façon crédible que la loi va les affecter négativement. Créer une telle liste d’exceptions est une tâche titanesque vouée à rester inachevée. Le filtrage des contenus devrait être rejeté dans son ensemble car c’est une mesure disproportionnée mettant en danger le droit fondamental de la liberté d’expression en ligne.

Nous pouvons y arriver !

Pour y parvenir, nous avons besoin de votre aide. La communauté FLOSS ne peut pas résoudre ces problèmes simplement avec du code : elle a un impact politique, la force du nombre et des allié⋅e⋅s au Parlement (européen). Nous avons déjà provoqué certains changements. Voici comment vous pouvez agir dès maintenant :

  1. signez la lettre ouverte sur SaveCodeShare (Note de traduction : en anglais, voir l’article de l’April qui soutient cette campagne) ;
  2. utilisez l’outil gratuit de Mozilla pour appeler les membres du Parlement européen ;
  3. tweetez aux principaux acteurs de la Commission des affaires légales du Parlement européen via FixCopyright (en anglais).

Note technique :

Trois acteurs sont impliqués dans le processus législatif. La Commission émet une première proposition de loi, à laquelle le Parlement européen et le Conseil de l’Union européenne peuvent proposer des amendements. Au sein du Parlement, la loi est d’abord discutée en Commission des affaires légales dans laquelle chaque groupe politique nomme un négociateur. Une fois que la Commission aura voté le compromis élaboré par les négociateurs, le texte sera soumis au vote en séance plénière du Parlement, avant que les négociations ne commencent avec les autres institutions. Le parcours législatif exact est disponible ici (en anglais).

Dans la mesure du possible et conformément à la loi, l’auteur [Julia Reda] renonce à tous les droits d’auteur et droits voisins sur ce texte.




Merci du signalement, ton bug peut attendre…

Magnus Manske est un développeur inconnu du grand public, on lui doit pourtant des contributions nombreuses et décisives pour le développement initial de Wikipédia, sa maintenance continue et son ingénierie, au point que les wikipédiens célèbrent chaque 25 janvier le Magnus Manske Day.

On imagine aisément à quel point ses journées sont bien remplies, d’autant qu’il donne son temps et son énergie pour le Libre sur son temps… libre !

Dans l’article dont nous vous proposons la traduction, il explique avec un brin de malice pourquoi les bugs apparemment les plus simples à traiter peuvent s’avérer les plus longs à régler… Deux minutes de lecture pour un petit article qui parlera à nos amis développeurs (ces indispensables travailleurs de l’ombre) comme il a parlé à Luc, notre tech warrior tout-terrain…

 

Non, je n’ai pas corrigé ton bogue, voici pourquoi

par Magnus Manske – article original : Why I didn’t fix your bug

Photo par Jason Krüger [CC BY-SA 4.0], via Wikimedia Commons
Beaucoup d’entre vous m’ont envoyé des rapports de bogue, des demandes de nouvelles fonctionnalités et signalé d’autres problèmes liés à mes outils dans le WikiVerse. Vous m’avez contacté via le BitBucket Issue tracker (et apparemment je suis aussi sur Phabricator maintenant), par Twitter, divers emails, des pages de discussion (les miennes, celles d’autres utilisateurs, via Wikitech, etc.), avec des applications de messagerie, et même en chair et en os.

Et je n’ai rien fait. Je n’ai même pas répondu.

Rien n’indique que j’ai vu le problème.

C’est frustrant, je sais. Tu veux juste que ce petit truc soit réparé. En tout cas, tu te figures que c’est un tout petit changement à opérer.

Voyons maintenant les ressources disponibles, ce qui, en l’occurrence, est mon temps. En commençant par les gros travaux (estimations générales, des variations saisonnières sont inévitables) :

Il y 24 h dans une journée

– 9 h de travail (y compris le trajet en voiture)

– 7 h de sommeil (j’espère en tout cas)

– 2 h de vie privée (manger, faire de l’exercice, prendre une douche, lire, passer du temps avec ma copine, etc.)

= il reste 6h

On ne peut pas discuter avec ça, n’est-ce pas ? Maintenant, 6h qui restent, c’est une estimation haute, évidemment ; le travail et la vie privée peuvent (et ça arrive) prendre bien plus de temps, sur une base quotidienne et très variable, comme c’est le cas pour chacun de nous.

Alors je peux régler ton problème, c’est ça ?

Voyons voir :

6h

– 1h de maintenance (redémarrage des outils, mise à jour des pages GLAM, ajout et correction des catalogues mix“n”match, etc.)

– 3h de développement/réécriture (parce que c’est de là que viennent les outils)

= il reste 2h

Deux heures par jour, ça fait beaucoup, non ? En réalité, c’est beaucoup moins, mais restons-en là pour l’instant. Quelques-uns de mes outils n’ont pas de problèmes, mais beaucoup en ont plusieurs en cours, donc supposons que chaque outil en a un :

2h = 120 min

/130 outils (estimation basse)1

= une moyenne de 55 secondes par outil

C’est assez de temps pour trouver et aborder le problème, ouvrir le(s) fichier(s) de code source, et… zut le temps s’est écoulé ! Désolé, problème suivant !

Donc, au lieu de tous les traiter, je m’occupe de l’un d’entre eux. Jusqu’à ce que ce soit réglé ou que j’abandonne. L’un ou l’autre peut prendre des minutes, des heures, voire des jours. Et pendant ce temps, je ne me penche pas sur les centaines d’autres problèmes. Parce que je ne peux rien faire pour eux à ce moment-là.

Alors, comment puis-je choisir un problème sur lequel travailler ? C’est une heuristique complexe calculée à partir des facteurs suivants :

  • Nombre d’utilisateurs concernés
  • Gravité (« problème de sécurité » vs « faute d’orthographe »)
  • Opportunité (ce qui signifie que je l’ai remarqué lorsqu’il a été déposé)
  • Disponibilité (est-ce que je me concentre sur autre chose lorsque je remarque le problème ?)
  • Plaisir possible et humeur du moment (eh oui, car je suis bénévole, ça vous dérange ?).

 

Aucun événement particulier n’a été à l’origine de la publication de ce billet. Je le garderai en référence pour en donner le lien, quand l’occasion se présentera.




Un cas de dopage : Gégé sous l’emprise du Dr Valvin

Quand un libriste s’amuse à reprendre et développer spectaculairement un petit Framaprojet, ça mérite bien une interview ! Voici Valvin, qui a dopé notre, – non, votre Geektionnerd Generator aux stéroïdes !

Gégé, le générateur de Geektionnerd, est un compagnon déjà ancien de nos illustrations plus ou moins humoristiques. Voilà 4 ans que nous l’avons mis à votre disposition, comme en témoigne cet article du Framablog qui vous invitait à vous en servir en toute occasion. Le rapide historique que nous mentionnions à l’époque, c’est un peu une chaîne des relais qui se sont succédé de William Carvalho jusqu’à Gee et ses toons en passant par l’intervention en coulisses de Cyrille et Quentin.

Vous le savez, hormis le frénétique Luc qu’on est obligés de piquer d’une flèche hypodermique pour l’empêcher de coder à toute heure, on développe peu à Framasoft. Aussi n’est-il guère surprenant que ce petit outil ludique soit resté en sommeil sans évolution particulière pendant ces dernières années où la priorité allait aux services de Dégooglisons.

Enfin Valvin vint, qui à l’occasion de l’ajout d’une tripotée de nouveaux personnages se mit à coder vite et bien, poursuivant avec la complicité de Framasky – ô Beauté du code libre ! – la chaîne amicale des contributeurs.

Mais faisons connaissance un peu avec celui qui vient d’ajouter généreusement des fonctionnalités sympathiques à Gégé.

Commençons par l’exercice rituel : peux-tu te présenter pour nos lecteurs et lectrices. Qui es-tu, Valvin ?

Salut Framasoft, je suis donc Valvin, originaire de Montélimar, j’habite maintenant dinch Nord avec ma petite famille. Je suis un peu touche-à-tout et il est vrai que j’ai une attirance particulière pour le Libre mais pas uniquement les logiciels.

 

Qu’est-ce qui t’a amené au Libre ? Tu es tombé dedans quand tu étais petit ou bien tu as eu droit à une potion magique ?

J’ai commencé en tant qu’ingénieur sur les technologies Microsoft (développement .NET, Active Directory, SQL Server…) J’avais bien commencé non ? Puis Pepper m’a concocté une potion et puis …. vous savez qu’elle ne réussit pas souvent ses potions ?

Plus sérieusement lors de mon parcours professionnel, j’ai travaillé dans une entreprise où Linux était largement déployé, ce qui m’a amené à rencontrer davidb2111, libriste convaincu depuis tout petit (il a dû tomber dans la marmite …). Et je pense que c’est lui qui m’a mis sur la voie du Libre…

Cependant ce qui m’a fait passer à l’action a été la 1re campagne « Dégooglisons Internet »… Elle a débuté juste après mon expérience de e-commerce, quand je gérais un petit site web de vente en ligne où j’ai découvert l’envers du décor : Google analytics, adwords, comparateurs de prix… et pendant que j’intégrais les premiers terminaux Android industriels.

Je suis maintenant un libriste convaincu mais surtout défenseur de la vie privée. Certains diront extrémiste mais je ne le pense pas.

Dans ta vie professionnelle, le Libre est-il présent ou bien est-ce compliqué de l’utiliser ou le faire utiliser ?
Aujourd’hui, je suis une sorte d’administrateur système mais pour les terminaux mobiles industriels (windows mobile/ce mais surtout Android). Pour ceux que ça intéresse, ça consiste à référencer du matériel, industrialiser les préparations, administrer le parc avec des outils MDM (Mobile Device Management), mais pas seulement !

Je suis en mission chez un grand compte (comme ils disent) où le Libre est présent mais pas majoritairement. On le retrouve principalement côté serveur avec Linux (CentOS), Puppet, Nagios/Centreon, PostgreSQL … (la liste est longue en fait). Après je travaille sur Android au quotidien mais j’ai un peu du mal à le catégoriser dans le Libre ne serait-ce qu’en raison de la présence des Google Play Services.

J’ai la chance d’avoir mon poste de travail sous Linux mais j’utilise beaucoup d’outils propriétaires au quotidien. (j’démarre même des fois une VM Windows … mais chuuuut !!).

Je suis assez content d’avoir mis en place une instance Kanboard (Framaboard) en passant par des chemins obscurs mais de nombreux utilisateurs ont pris en main l’outil ce qui en fait aujourd’hui un outil officiel.

On découvre des choses diverses sur ton blog, des articles sur le code et puis un Valvin fan de graphisme et surtout qui est prêt à contribuer dès qu’il y a passion ? Alors, tu as tellement de temps libre pour le Libre ?

Du temps quoi ?… Malheureusement, je n’ai pas beaucoup de temps libre entre le travail, les trajets quotidien (plus de 2 heures) et la famille. Du coup, une fois les enfants couchés, plutôt que regarder la télé, j’en profite (entre deux dessins).
Mes contributions dans le libre sont principalement autour du projet de David Revoy, Pepper & Carrot. J’ai la chance de pouvoir vivre l’aventure à ses côtés ainsi que de sa communauté. Et dans l’univers de la BD, c’est inédit ! D’ailleurs je te remercie, Framasoft, de me l’avoir fait découvrir 🙂
Si je peux filer un petit coup de main avec mes connaissances sur un projet qui me tient à cœur, je n’hésite pas. Et même si ce n’est pas grand-chose, ça fait plaisir d’apporter une pierre à l’édifice et c’est ça aussi la magie du Libre !
J’ai eu parfois l’ambition de lancer moi même des projets libres mais j’ai bien souvent sous-estimé le travail que ça représentait …

Et maintenant, tu t’attaques au geektionnerd, pourquoi tout à coup une envie d’améliorer un projet/outil qui vivotait un peu ?
Je dois avouer que c’est par hasard. J’ai vu un message sur Mastodon qui m’a fait découvrir le projet. Il n’y a pas si longtemps, je m’étais intéressé au projet Bird’s Dessinés et j’avais trouvé le concept sympa. Mais tout était un peu verrouillé, notamment les droits sur les réalisations. J’aime bien le dessin et la bande dessinée, le projet du générateur de Geektionnerd m’a paru très simple à prendre en main… du coup, je me suis lancé !

Tu peux parler des problèmes du côté code qui se sont posés, comment les as-tu surmontés  ?
Globalement, ça s’est bien passé jusqu’au moment où j’ai voulu ajouter des images distantes dans la bibliothèque. Le pire de l’histoire c’est que ça fonctionnait bien à première vue. On pouvait ajouter toutes les images que l’on voulait, les déplacer… Nickel ! Et puis j’ai cliqué sur « Enregistrer l’image » et là… j’ai découvert la magie de  CORS !

CORS signifie Cross Origin Ressource Sharing et intervient donc lorsque le site web tente d’accéder à une ressource qui ne se situe pas sur son nom de domaine.
Il est possible de créer une balise image html qui pointe vers un site extérieur du type :

<img src="https://www.peppercarrot.com/extras/html/2016_cat-generator/avatar.php?seed=valvin" alt="c'est mon avatar" />

En revanche, récupérer cette image pour l’utiliser dans son code JavaScript, c’est possible mais dans certaines conditions uniquement. Typiquement, si j’utilise jquery et que je fais :

$.get("https://www.peppercarrot.com/extras/html/2016_cat-generator/avatar.php?seed=Linux", function(data){
    $("#myImg").src = data;
});

On obtient :

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://www.peppercarrot.com/extras/html/2016_cat-generator/avatar.php?seed=Linux. (Reason: CORS header 'Access-Control-Allow-Origin' missing).

En revanche, si on utilise une image hébergée sur un serveur qui autorise les requêtes Cross-Origin, il n’y a pas de souci :

$.get("https://i.imgur.com/J2HZir3.jpg", function(data){
    $("#myImg").src = data;
});

Tout cela en raison de ce petit en-tête HTTP que l’on obtient du serveur distant :

Access-Control-Allow-Origin *

où `*` signifie tout le monde, mais il est possible de ne l’autoriser que pour certains domaines.
Avec les canvas, ça se passait bien jusqu’à la génération du fichier PNG car on arrivait au moment où l’on devait récupérer la donnée pour l’intégrer avec le reste de la réalisation. J’avais activé un petit paramètre dans la librairie JavaScript sur l’objet Image

image.crossOrigin = "Anonymous";

mais avec ce paramètre, seules les images dont le serveur autorisait le Cross-Origin s’affichaient dans le canvas et la génération du PNG fonctionnait. Mais c’était trop limitatif.

Bref, bien compliqué pour par grand-chose !

J’ai proposé de mettre en place un proxy CORS, un relais qui rajoute simplement les fameux en-têtes mais ça faisait un peu usine à gaz pour ce projet. Heureusement, framasky a eu une idée toute simple de téléchargement d’image qui a permis de proposer une alternative.
Tout cela a fini par aboutir, après plusieurs tentatives à ce Merge Request : https://framagit.org/framasoft/geektionnerd-generator/merge_requests/6

Et après tous ces efforts quelles sont les fonctionnalités que tu nous as apportées sur un plateau ?

Chaud devant !! Chaud !!!

  • Tout d’abord, j’ai ajouté le petit zoom sur les vignettes qui était trop petites à mon goût

  • Ensuite, j’ai agrandi la taille de la zone de dessin en fonction de la taille de l’écran. Mais tout en laissant la possibilité de choisir la dimension de la zone car dans certains cas, on ne souhaite qu’une petite vignette carrée et cela évite de ré-éditer l’image dans un second outil.

  • Et pour terminer, la possibilité d’ajouter un image depuis son ordinateur. Cela permet de compléter facilement la bibliothèque déjà bien remplie 🙂

Merci ! D’autres développements envisagés, d’autres projets, d’autres cartoons dans tes cartons ?

D’autres développements pour Geektionnerd ? Euh oui, j’ai plein d’idées … mais est ce que j’aurai le temps ?
– intégration Lutim pour faciliter le partage des réalisations
– recherche dans la librairie de toons à partir de tags (nécessite un référencement de méta-data par image)
– séparation des toons des bulles et dialogues : l’idée serait de revoir la partie gauche de l’application et trouver facilement les différents types d’images. Notamment en découpant par type d’image : bulles / personnages / autres.
– ajout de rectangles SVG pour faire des cases de BD
– amélioration de la saisie de texte (multi-ligne) et sélection de la fonte pour le texte
– …
Je vais peut-être arrêter là 🙂

Sinon dans les cartons, j’aimerais poursuivre mon projet Privamics dont l’objectif est de réaliser des mini-BD sur le sujet de la vie privée de façon humoristique. Mais j’ai vu avec le premier épisode que ce n’était pas une chose si facile. Du coup, je privilégie mon apprentissage du dessin 🙂

Bien entendu, Pepper & Carrot reste le projet auquel je souhaite consacrer le plus de temps car je trouve que le travail que fait David est tout simplement fantastique !

Le mot de la fin est pour toi…
Un grand merci à toi Framasoft, tu m’as déjà beaucoup apporté et ton projet me tient particulièrement à cœur.

Vive le Libre !!! 🙂




Code open source contre gros système

57 lignes de code et deux ou trois bidules électroniques feraient aussi bien voire mieux qu’un gros système coûteux. Telle est la démonstration que vient de faire un développeur australien.
L’expérience que relate ici Tait Brown relève du proof of concept, la démonstration de faisabilité. La spectaculaire économie de moyens numériques et financiers qu’il démontre avec 57 lignes de code open source et des appareils à la portée d’un bidouilleur ordinaire n’est peut-être pas une solution adaptable à grande échelle pour remplacer les puissants et massifs systèmes propriétaires mis en place par des entreprises. Pas plus que les services libres de Framasoft n’ambitionnent de remplacer les GAFAM, mais démontrent que des solutions alternatives libres et plus respectueuses sont possibles et viables, et de plus en plus disponibles.

Outre le pied de nez réjouissant du hacker occasionnel aux institutions locales (ici, la police de l’état australien de Victoria) qui ont confié un traitement informatique à des sociétés privées, ce petit témoignage ouvre au moins une question : le code est mis au service de la police au bénéfice des citoyens (repérer les voitures volées, pister la délinquance…), mais peut fort bien ne faire qu’augmenter la surveillance de masse au détriment des mêmes citoyens, avec les conséquences pas du tout triviales qu’on connaît et dénonce régulièrement. Le fait que le code open source soit auditable est-il un garde-fou suffisant ?

 

Comment j’ai recréé un logiciel de 86 millions de dollars en 57 lignes de code

par Tait Brown

Publication originale : How I replicated an $86 million project in 57 lines of code
Traduction Framalang : xi, Lyn., goofy, framasky, Lumibd, Penguin

Quand un essai à base de technologie open source fait le boulot « suffisamment bien ».

La police est le principal acteur du maintien de l’ordre dans l’État du Victoria, en Australie. Dans cet État, plus de 16 000 véhicules ont été volés l’an passé, pour un coût d’environ 170 millions de dollars. Afin de lutter contre le vol de voitures, la police teste différentes solutions technologiques.

Pour aider à prévenir les ventes frauduleuses de véhicules volés, VicRoads propose déjà un service en ligne qui permet de vérifier le statut d’un véhicule en saisissant son numéro d’immatriculation. L’État a également investi dans un scanner de plaque minéralogique : une caméra fixe sur trépied qui analyse la circulation pour identifier automatiquement les véhicules volés.

Ne me demandez pas pourquoi, mais un après-midi, j’ai eu envie de réaliser un prototype de scanner de plaques minéralogiques embarqué dans une voiture, qui signalerait automatiquement tout véhicule volé ou non immatriculé. Je savais que tous les composants nécessaires existaient et je me suis demandé à quel point il serait compliqué de les relier entre eux.

Mais c’est après quelques recherches sur Google que j’ai découvert que la Police de l’État du Victoria avait récemment testé un appareil similaire dont le coût de déploiement était estimé à 86 millions de dollars australiens. Un commentateur futé a fait remarquer que 86 millions de dollars pour équiper 220 véhicules, cela représentait 390 909 AUSD par véhicule.
On devait pouvoir faire mieux que ça.

 

Le système existant qui scanne les plaques minéralogiques avec une caméra fixe

Les critères de réussite

Avant de commencer, j’ai défini à quelles exigences clés devait répondre la conception de ce produit.

Le traitement de l’image doit être effectué localement
Transmettre en continu le flux vidéo vers un site de traitement centralisé semblait l’approche la moins efficace pour répondre au problème. La facture pour la transmission des données serait énorme, de plus le temps de réponse du réseau ne ferait que ralentir un processus potentiellement assez long.
Bien qu’un algorithme d’apprentissage automatique centralisé ne puisse que gagner en précision au fil du temps, je voulais savoir si une mise en œuvre locale sur un périphérique serait « suffisamment bonne ».

Cela doit fonctionner avec des images de basse qualité
Je n’avais ni caméra compatible avec un Raspberry Pi, ni webcam USB, j’ai donc utilisé des séquences vidéo issues de dashcam [NdT : caméra installée dans un véhicule pour enregistrer ce que voit le conducteur], c’était immédiatement disponible et une source idéale de données d’échantillonnage. En prime, les vidéos dashcam ont, en général, la même qualité que les images des caméras embarquées sur les véhicules.

Cela doit reposer sur une technologie open source
En utilisant un logiciel propriétaire, vous vous ferez arnaquer chaque fois que vous demanderez un changement ou une amélioration, et l’arnaque se poursuivra pour chaque demande ultérieure. Utiliser une technologie open source évite ce genre de prise de tête.

Solution

Pour l’expliquer simplement, avec ma solution, le logiciel prend une image à partir d’une vidéo dashcam, puis l’envoie vers un système de reconnaissance des plaques minéralogiques open source installé localement dans l’appareil, il interroge ensuite le service de contrôle des plaques d’immatriculation et renvoie le résultat pour affichage.
Les données renvoyées à l’appareil installé dans le véhicule de police comprennent : la marque et le modèle du véhicule (pour vérifier si seules les plaques ont été volées), le statut de l’immatriculation et la notification d’un éventuel vol du véhicule.
Si cela semble plutôt simple, c’est parce que c’est vraiment le cas. Le traitement de l’image, par exemple, peut être opéré par la bibliothèque openalpr. Voici vraiment tout ce qu’il faut pour reconnaître les caractères sur les plaques minéralogiques :

 openalpr.IdentifyLicense(imagePath, function (error, output) {
 // handle result
 });
 (le code est sur Github)

Mise en garde mineure
L’accès public aux API de VicRoads n’étant pas disponible, les vérifications de plaques d’immatriculation se font par le biais du web scraping (NdT : une technique d’extraction automatisée du contenu de sites web) pour ce prototype. C’est une pratique généralement désapprouvée, mais il ne s’agit ici que d’un test de faisabilité et je ne surcharge pas les serveurs de quiconque.

Voici à quoi ressemble mon code, vraiment pas propre, utilisé pour tester la fiabilité de la récupération de données :

(le code est sur Github)

Résultats

Je dois dire que j’ai été agréablement surpris.

Je m’attendais à ce que la reconnaissance des plaques minéralogiques open source soit plutôt mauvaise. De plus, les algorithmes de reconnaissance d’images ne sont probablement pas optimisés pour les plaques d’immatriculation australiennes.

Le logiciel a été capable de reconnaître les plaques d’immatriculation dans un champ de vision large.

Annotations ajoutées sur l’image. Plaque minéralogique identifiée malgré les reflets et l’axe de prise de vue

Toutefois, le logiciel a parfois des problèmes avec des lettres particulières.

Mauvaise lecture de la plaque, le logiciel a confondu le M et le H

Mais… il finit par les corriger :

Quelques images plus tard, le M est correctement identifié à un niveau de confiance plus élevé

 

Comme vous pouvez le voir dans les deux images ci-dessus, le traitement de l’image quelques images plus tard a bondi d’un indice de confiance de 87% à un petit peu plus de 91%.

Il s’agit de solutions très simples au niveau de la programmation, qui n’excluent pas l’entraînement du logiciel de reconnaissance des plaques d’immatriculation avec un ensemble de données locales.
Je suis certain que la précision pourrait être améliorée en augmentant le taux d’échantillonnage, puis en triant suivant le niveau de confiance le plus élevé. On pourrait aussi fixer un seuil qui n’accepterait qu’une confiance supérieure à 90% avant de valider le numéro d’enregistrement.
Il s’agit de choses très simples au niveau de la programmation, qui n’excluent pas l’entraînement du logiciel de reconnaissance des plaques d’immatriculation avec un jeu de données locales.

La question à 86 000 000 dollars

Pour être honnête, je n’ai absolument aucune idée de ce que le chiffre de 86 millions de dollars inclut – et je ne peux pas non plus parler de la précision d’un outil open source sans entraînement spécifique adapté au pays par rapport au système pilote BlueNet.
Je m’attendrais à ce qu’une partie de ce budget comprenne le remplacement de plusieurs bases de données et applications logicielles existantes pour répondre à des demandes de renseignements sur les plaques d’immatriculation à haute fréquence et à faible latence plusieurs fois par seconde par véhicule.
D’un autre côté, le coût de 391 000 dollars par véhicule semble assez élevé, surtout si le BlueNet n’est pas particulièrement précis et qu’il n’ existe pas de projets informatiques à grande échelle pour la mise hors service ou la mise à niveau des systèmes dépendants.

Applications futures

Bien qu’on puisse aisément être soucieux de la nature orwellienne d’un réseau qui fonctionne en continu de mouchards à plaques minéralogiques, cette technologie a de nombreuses applications positives. Imaginez un système passif qui analyse les autres automobilistes à la recherche d’une voiture de ravisseurs et qui avertit automatiquement et en temps réel les autorités et les membres de la famille de leur emplacement et de leur direction.

Les véhicules Tesla regorgent déjà de caméras et de capteurs capables de recevoir des mises à jour OTA (NdT : Over The Air, c’est-à-dire des mises à jour à distance) – imaginez qu’on puisse en faire une flotte virtuelle de bons Samaritains. Les conducteurs Uber et Lyft pourraient également être équipés de ces dispositifs pour augmenter considérablement leur zone de couverture.

En utilisant la technologie open source et les composants existants, il semble possible d’offrir une solution qui offre un taux de rendement beaucoup plus élevé – pour un investissement bien inférieur à 86 millions de dollars.




Un hackathon pour Sympa

Pendant que vous cherchez la contrepèterie dans ce titre purement factuel, on vous explique : Sympa, c’est le logiciel qui nous permet de gérer Framalistes, un des services de notre modeste plan de libération du monde© !

Marc Chantreux a lancé une invitation à tous les fans de Sympa (eh oui, ils sont sympas, on va se débarrasser de ça tout de suite) pour le rejoindre dans un grand hackathon à Strasbourg le week-end du premier avril 2017.

C’est super, mais… c’est quoi ?

 

 

 

 

 

Bonjour Marc, est-ce que tu veux bien te présenter ?

Je m’appelle Marc Chantreux, je suis libriste (par conviction éthique et technique) depuis les années 90 et suis actuellement informaticien à l’université de Strasbourg où j’ai géré sympa pendant 5 ans.

Sympa, le logiciel libre qui nous sert à gérer Framalistes, va fêter ses 20 ans, c’est bien ça ?

C’est ça et je me suis connecté pour la première fois à Internet la même année. Ce qui m’a immédiatement plu à l’époque, ce n’était pas la quantité de documentation disponible (parce qu’on avait déjà des e-zines et autres documentations qui circulaient sur CD-Rom ou supports imprimés) mais la possibilité de poser directement des questions aux experts dans une ambiance extrêmement ouverte et respectueuse. Les deux principaux outils pour cela étaient Usenet et les listes de discussion. En France, un gros hébergeur de listes était Universalistes qui tournait déjà (qui tourne toujours) sous sympa.

Ce logiciel a été créé et maintenu par la communauté universitaire française depuis l’origine. Entre temps, sympa a été adopté dans le monde entier et s’est enrichi de fonctionnalités nécessaires au travail collaboratif pour lequel les listes étaient utilisées (documents partagés, archives, modération, délégation de droits, etc.).

Je me réjouis de voir que Framasoft ait monté une instance de sympa pour sa communauté mais perso, j’aurais utilisé « framagroupes » comme nom.

À cette occasion tu organises un fork communautaire et un hackathon. Tu peux nous expliquer ? Nan, parce que Framasky, il m’a demandé de t’interviewer mais j’y comprends que pouic. 🙂

Ces dernières années, la communauté universitaire a affecté de moins en moins de ressources jusqu’à ce que tout s’arrête complètement au courant de l’année dernière. La communauté est pourtant forte de millions d’utilisateurs et il n’existe pas d’alternative crédible si on considère sympa dans son ensemble. J’ai donc proposé à la communauté de se rassembler pour s’organiser et posé les bases d’un développement qui ne repose plus sur le seul acteur historique (RENATER). Les 20 ans de sympa tombaient un week-end, c’était une belle occasion.

RENATER a réagi très positivement à cette initiative et nous a rapidement prêté assistance, en ouvrant une partie de l’infrastructure, en parrainant la venue du leader historique du projet — David Verdin — et en nous rassurant sur leur volonté de rester investi dans le projet. J’ai eu des échanges téléphoniques et électroniques avec leur direction technique et je suis confiant dans la perspective de voir RENATER redonner de la force de frappe à sympa.

Et c’est quoi, l’objectif de ce hackathon ? Sur quel critère le jugeras-tu réussi ?

L’objectif de ce hackathon est d’initier les projets qui permettront aux utilisateurs de sympa d’avoir accès plus simplement à un grand nombre de fonctionnalités. Il nous faut au passage nous mettre d’accord sur des pratiques communes de développement mais le plus important pour moi n’est pas là.

Je suis membre de longue date de la communauté Perl et je suis toujours ému par l’énergie qui se dégage du sentiment que nous partageons tous d’appartenir à une communauté soudée, au service de millions d’utilisateurs et vivant une grande aventure technique avec des défis à relever au quotidien pour produire le meilleur logiciel possible. Si nous arrivons à faire germer cet esprit dans la communauté sympa naissante, alors je serais heureux.

Le hackathon, c’est que pour les développeurs, ou tout le monde peut contribuer ?

Sympa est comme tout logiciel libre : sa valeur réside dans son utilité et non dans son code.

Pour le rendre utile, il faut aussi le rendre accessible et visible et nous avons besoin de faire plein de choses nécessitant plein de compétences ! Dites-moi ce que vous voulez ou savez faire et j’aurais probablement des tâches à vous proposer. Celles qui me viennent sont : collecter les besoins et retours des utilisateurs, organiser ou participer à des événements, faire du graphisme et de la communication, nous aider à réaliser de la documentation, créer et animer la formation, assister les communautés d’utilisateur, faire de la traduction…

Il va y avoir du beau monde, dans ce hackathon, les copains de Yunohost, notamment. Qui d’autre ?

De nombreux acteurs associatifs en faveur de l’auto-hébergement et de l’internet neutre (par exemple Framasoft, YUNoHost, ARN qui est un FAI associatif alsacien) mais aussi des hackers du Libre User Group alsacien et du Hackstub, des membres de la communauté universitaire (Universités de Strasbourg et Oslo et RENATER qui est le FAI des universités françaises) ainsi que les sociétés Hackcendo et Linuxia.

Et ça se passe où ? Il faut s’inscrire quelque part ?

Ça se passe au portique de l’université de Strasbourg mais les inscriptions sont maintenant closes. Désolé…

Du coup, on peut participer à distance ? Ou aider d’une autre façon ?

Bien sûr : le mieux est de rejoindre le canal IRC #sympa sur freenode dès maintenant et de dire que vous êtes intéressés par la contribution. Si vous avez du mal avec l’anglais, vous pouvez aussi vous abonner à la liste sympa-fr (https://listes.renater.fr/sympa/info/sympa-fr) ou me contacter directement.

Sympa, ça peut gérer des listes de diffusion vraiment balaises ? Genre quoi ?

Genre j’ai personnellement géré des listes de 140 000 abonnés ou le goulot d’étranglement n’était pas sympa mais l’infra de messagerie. Les listes permettant de contacter l’ensemble des personnels de l’enseignement supérieur tournent avec sympa et il existe des groupes qui dépassent le million d’abonnés.

Mais si on se lance dans le concours du plus gros site, je dirais que le principal intérêt de sympa réside non pas dans sa capacité d’envoyer des millions de messages mais de réussir à les envoyer en respectant l’état de l’art dans les pratiques relatives à la lutte anti-spam (DMARC, DKIM…) et de donner la possibilité à des administrateurs d’industrialiser la création et la maintenance d’un grand nombre de listes (l’université de Strasbourg en compte près de 35 000).

Comme d’hab, nous te laissons le mot de la fin, lâche-toi.

Lors de l’apparition des premiers web fora, j’ai vu les communautés se diviser autour des outils de discussion. les « surfers » (qui aiment les fora pour leur côté immédiat, simple et « beau ») et les fans de la messagerie électronique qui apprécient le degré de liberté qui leur est donné de présenter et traiter les messages comme ils l’entendent. Les deux approches sont valables et ne devraient pas être un frein pour ce qui compte réellement : l’échange ! Avec ses outils (postage, archives en ligne, dépôt de documents) sympa est soit un gestionnaire de listes haut de gamme soit le système de forum avec la pire interface web du monde.

L’urgence de sympa, c’est donc son interface web et c’est là-dessus que nous allons mettre le paquet.

Pour en savoir plus, et surtout donner un coup de main, c’est par ici




Des routes et des ponts (16) – vers de meilleures stratégies

Aujourd’hui menu allégé (après les agapes), avec un bref chapitre de Des routes et des ponts par Nadia Eghbal, ouvrage dont tous les chapitres précédents sont .
Il s’agit cette fois-ci de dresser la liste des principes qui devraient gouverner le soutien durable aux projets et infrastructures open source.

Traduction Framalang :  Penguin, goofy, xi, Lumi, xXx, Mika

Élaborer des stratégies d’assistance efficaces

Même si les gens sont de plus en plus intéressés par les efforts pour soutenir les infrastructures numériques, les initiatives actuelles sont encore récentes, faites pour des cas particuliers ou fournissent seulement un support partiel (comme le partage d’avantages fiscaux par des organisations à but non lucratif avec des groupes extérieurs à celles-ci).

Le développement de stratégies de soutien efficaces demande une compréhension fine de la culture open source qui caractérise une très grande partie de notre infrastructure numérique, mais aussi de reconnaître que beaucoup de choses ont changé dans les cinq dernières années, y compris la définition même de l’open source.

L’argent seul ne suffira pas à répondre aux problèmes d’un projet d’infrastructure en difficulté, parce que l’open source s’épanouit grâce aux ressources humaines et non financières. Il existe beaucoup de façons d’accroître les ressources humaines, comme distribuer la charge de travail parmi davantage de contributeurs ou encourager les entreprises à faire publier en open source une partie du travail de leurs employés. Une stratégie de soutien efficace doit inclure plusieurs façons de générer du temps et des ressources au-delà du financement direct du développement. Elle doit partir du principe que l’approche open source n’est pas défectueuse en elle-même, mais manque simplement de ressources.

Soutenir les infrastructures nécessite d’intégrer le concept d’intendance en lieu et place du concept de contrôle. Comme nous l’avons vu, les infrastructures numériques ne ressemblent pas aux infrastructures physiques. Elles sont réparties entre de multiples acteurs et organisations, avec des projets de toute forme et de toute taille, et il est difficile de prédire quels projets deviendront un succès ou qui y contribuera sur le long terme.

Photo par Frédéric Bisson (CC BY 2.0)

 

Avec cela en tête, voici quelques clés pour élaborer une stratégie d’assistance efficace :

Adopter la décentralisation, plutôt que s’y opposer

Les ressources de l’open source sont destinées à être partagées, c’est en partie ce qui leur donne autant d’impact.
Utiliser la force que donne l’aspect communautaire comme un levier, plutôt que de recentraliser l’autorité.

Travailler étroitement avec les communautés informatiques existantes.

Les communautés informatiques sont actives, soudées et savent se faire entendre. Faites appel à elles plutôt que de prendre une décision en aparté. Les voix les plus sonores des communautés agissent comme un signal de danger quand un problème nécessite d’être soulevé.

Envisager une approche globale du soutien aux projets

Les projets ont besoin de bien plus que du code ou de l’argent, parfois même ils n’ont besoin ni de l’un ni de l’autre. Le soutien sur le long terme est davantage une question de temps accordé que d’argent. La revue de code, la documentation technique, les tests de code, la soutien de la communauté, et la promotion du projet constituent un ensemble de ressources importantes.

Aider les mainteneurs de projets à anticiper

Aujourd’hui, les efforts pour soutenir l’infrastructure numérique ont tendance a être uniquement de la réactivité liée aux circonstances ponctuelles. En plus des projets existants, il existe sûrement de nouveau projets qui ont besoin d’être lancés et accompagnés.
Pour les projets existants, les mainteneurs trouveront un grand avantage à pouvoir planifier en vue des trois à cinq ans à venir, et pas seulement pour six mois ou un an.

Voir les opportunités, pas seulement les risques

Soutenir l’open source de nos jours, cela ne consiste pas uniquement à éviter les scénarios catastrophes (par exemple les failles de sécurité), mais plutôt à donner les moyens à davantage de personnes de réaliser davantage de choses. Ce concept est une caractéristique essentielle de la culture open source actuelle, et permet aussi de mettre en place un soutien pérenne. Tenez compte dans votre stratégie de la façon dont vous pourriez accueillir davantage de personnes d’horizons, de compétences et de talents différents, plutôt que de limiter l’activité pour favoriser les personnes qui participent déjà.

David Heinemeier Hansson, le créateur de Ruby on Rails, compare l’open source à un récif de corail :

« C’est un milieu plus fragile que vous ne le pensez, et il est difficile de sous-estimer la beauté qui est involontairement en jeu. Marchez avec précaution. »

Photo par Wicker Paradise – (CC-BY 2.0)




Se lancer dans l’open source : un témoignage engageant

Comment participer à des projets open source et s’y sentir légitime ? La réponse habituelle un peu désinvolte consiste à dire : « il suffit de commencer à proposer ne serait-ce qu’un signalement de bug ou une correction mineure dans la documentation et hop ». En commençant par une contribution minime, on peut donc trouver sa place dans une équipe. Théoriquement, c’est exact.

Mais quand on est une jeune femme à peine sortie de ses études d’informatique et qu’on éprouve un peu d’appréhension au contact des contributeurs supposés expérimentés, rien n’est tout à fait simple.

Comme on le lira dans le témoignage de Shubheksha, il faut non seulement parvenir à surmonter son manque de confiance en soi, mais aussi avoir la chance de rencontrer sur son chemin des mentors qui vous accueillent avec bienveillance, vous guident et vous invitent à contribuer davantage encore.

Le parcours cahoteux d’une débutante dans le monde de l’open source

Article original paru dans Medium : A Beginner’s Very Bumpy Journey Through The World of Open Source

Par Shubheksha

Traduction :  Lyn, audionuma, goofy, Lumibd, Manguito,et un anonyme

shubhekshaAvez-vous atterri ici en recherchant des conseils sur la meilleure manière de contribuer à l’open source ? Il y a des milliers d’histoires de ce genre sur Internet, n’est-ce pas ?
Je suis sûre que vous en avez lu beaucoup à présent, car vous essayez de contribuer depuis un bon moment. Et vous avez toujours l’impression de ne pas avoir progressé.
Je connais ce sentiment. J’étais exactement dans la même situation il y a quelques semaines. Laissez-moi vous conter mon histoire.

Voilà à peu près deux ans que j’essaie de contribuer à l’open source.

Oui. Deux ans.

Et il y a bien une chose que je peux affirmer : c’est intimidant. C’est dur de commencer. Vous devez apprendre comment travailler sur un long code source. Vous devez apprendre et adopter les règles de style de code d’un projet.

Tout paraît confus. L’ordre des instructions, comment les différents modules interagissent entre eux, comment et pourquoi le code est organisé de la manière dont il l’est : tout cela constitue un grand labyrinthe.

Je ressens cela en permanence car je ne suis, après tout, qu’une amatrice qui essaie d’en apprendre autant qu’elle le peut.

J’ai donc choisi de suivre la voie la plus facile : la correction de fautes dans la documentation ou les commentaires, et la résolution de bugs triviaux où il était évident de trouver ce qui devait être modifié. Je ne voulais pas poser trop de questions ni essayer de comprendre l’ensemble du code.

Chaque fois que je voulais contribuer, j’allais sur github — ou un autre gestionnaire de bugs – et j’essayais de rechercher des problèmes étiquetés « facile », « débutant », « premier bug facile ». Après en avoir consulté des centaines, je trouvais quelque chose de suffisamment simple à traiter sans beaucoup d’aide extérieure.

Alors, cela a bien fonctionné jusqu’au moment où j’ai pris conscience que je pourrais mieux utiliser les compétences que j’étais en train de développer. J’avais appris tant de nouvelles choses, mais je ne voyais pas à quoi j’aurais pu les utiliser. Apprendre sans mettre en application, c’est bien peu gratifiant. J’étais bloquée sur un palier et je n’avançais plus du tout.

Alors, il est arrivé quelque chose qui m’a terriblement effrayée en tant que nouvelle contributrice qui essaie de naviguer dans le monde de l’open source. J’avais trouvé un bug qui avait l’air assez facile dans un grand projet renommé.

J’ai pensé qu’il valait mieux demander quelques éclaircissements avant de procéder à la moindre modification car je craignais de tout bousiller. J’ai donc envoyé un commentaire indiquant que j’étais une nouvelle contributrice, et demandant quelle serait la meilleure manière de modifier un bout de texte pour corriger le bug.

La réponse que je reçus fut :

« Si tu n’arrives pas à déterminer comment effectuer cette modification, c’est que tu n’es pas qualifiée pour effectuer cette modification. »

Cette réponse me laissa complètement décontenancée, et m’effraya davantage encore à l’idée de poser des questions lorsque je ne comprenais pas quelque chose à propos d’un projet.

Peut-être étais-je indésirable parce que je n’en savais pas assez ? Peut-être devais-je travailler davantage pour acquérir des compétences au lieu de poser des questions stupides et maladroites à des personnes expérimentées beaucoup trop occupées pour me répondre ?

C’est aussi à cette époque que ma recherche d’un mentor a commencé. J’ai pensé que si je connaissais quelqu’un avec qui je serais plus à l’aise pour poser des questions, les choses se passeraient bien et je pourrais me rendre plus utile.

J’ai donc écrit à de nombreuses personnes en leur demandant de m’aider à débuter, vu que je me sentais particulièrement intimidée par mes précédentes expériences. J’ai reçu beaucoup de réponses positives, pleines d’encouragements, mais je n’ai jamais exactement trouvé ce que je cherchais.

J’avais l’impression de buter contre un environnement clos dans le monde ouvert de l’open source.

Tout semblait suggérer que je n’avais qu’à m’y mettre et à ne pas avoir peur. Mais je n’étais pas prête à ce moment là.

Moi, fuyant le monde du logiciel open source

Ma découverte de Mozilla

Par une belle soirée, alors que je cherchais des bugs à corriger, j’ai atterri sur le projet de Mozilla qui vous aide à tester des extensions web. J’étais contente de voir qu’il y avait quelques problèmes étiquetés comme « premier bug facile » mais aucun d’entre eux n’était aussi simple que de corriger une petite coquille.

Bon sang, j’en suis tellement heureuse maintenant.

J’ai commencé à travailler sur l’un de ces bugs, mais j’ai vite compris qu’il me faudrait poser des questions si je voulais être capable de résoudre le problème. J’ai parcouru le code source. Après avoir compris les grandes lignes du problème, j’ai demandé plus d’informations. et voila ! J’ai été capable de résoudre le problème une fois que j’ai eu tous les détails nécessaires.

Maintenant que j’ai soumis trois pull requests [NDT : demandes de modification du code source] (l’une a été acceptée, les deux autres sont en passe de l’être), je suis heureuse d’avoir franchi le pas. Je suis contente de ne pas avoir hésité à poser des questions pertinentes, même si je risquais parfois d’avoir l’air de poser des questions stupides.

Ce n’est pas un problème de ne pas tout savoir et de progresser par étapes pour apprendre quelque chose de nouveau.

Les gens de Mozilla qui encadrent ces corrections m’ont beaucoup aidée et ont toujours été très positifs. Ils m’ont guidée du début à la fin, prenant le temps de m’expliquer les choses de façon à la fois simple et très détaillée. Et cela malgré le fait qu’ils n’auraient mis que quelques heures à corriger ces problèmes eux-mêmes au lieu de prendre le temps de me guider vers une solution de mon cru, dont la conception m’a pris plusieurs jours.

J’ai appris et découvert énormément de choses juste en travaillant sur ces trois problèmes basiques. Et je suis vraiment excitée à l’idée de travailler sur des problèmes encore plus difficiles et d’augmenter ma compréhension de ce sujet et mes connaissances.

l'insatiable vieux dino de Mozilla se goinfre de bugs
l’insatiable vieux dino de Mozilla se goinfre de bugs

Je ne peux pas les remercier assez pour cette expérience tellement positive et enrichissante, qui m’amène à installer Firefox localement et à parcourir les bugs sur Bugzilla un jour sur deux (je garde mes questions sur « Pourquoi » et « Comment » pour un billet plus long).

Je prévois de contribuer à Mozilla aussi régulièrement que possible. À chaque fois que j’ai posé une question pertinente, que ce soit sur IRC, Github ou Bugzilla, j’ai reçu des réponses très aimables.
Jusqu’à aujourd’hui, j’ai résolu trois problèmes dans web-ext, et j’ai eu un correctif accepté et intégré dans Firefox.

Mes contributions ont été remarquées par la communauté, et j’ai aussi été nommée dans le « Addons Contribution Recognition document » [NdT : la liste des contributeurs aux extensions de Mozilla].

En définitive, mes expériences de ces dernières semaines ont été vraiment merveilleuses. J’ai appris tellement de choses, petites et grandes, qu’aucun manuel de programmation n’aurait pu m’apprendre.
Voici mes conseils pour les développeurs débutants qui veulent contribuer à un projet open source :

Conseil n°1 : n’ayez pas peur de poser des questions

Je ne saurais trop insister sur ce point. J’ai perdu beaucoup de temps parce que je ne cessais de me censurer, et c’était ma plus importante inhibition.

Tout le monde a peur de paraître stupide. Mais ne laissez pas cette peur paralysante devenir une entrave à votre progression.

Il est normal de demander si vous ne comprenez pas quelque chose qui est en rapport avec le projet. Les développeurs du projet sont devenus des experts au fil des années. Ils peuvent vous aider très rapidement. Sinon vous risquez de perdre des heures le nez dans le code source à essayer de deviner quelque chose que vous n’êtes même pas censés savoir au départ.

Mais quand vous demandez des informations, vérifiez si elles ne sont pas déjà disponibles dans une documentation ou une recherche Google. Ainsi, vous prendrez garde à respecter le temps libre des développeurs du projet.

Conseil n°2 : c’est normal d’avoir des lacunes

On ne s’attend pas à ce que vous sachiez tout de A à Z lorsque vous commencez à contribuer à un projet. Le processus, c’est plutôt que vous appreniez et gagniez en compétence en résolvant des problèmes de plus en plus difficiles, et en vous familiarisant avec le projet et les outils qu’il utilise. Le temps nécessaire pour cela varie d’un projet à l’autre et d’une personne à l’autre.

Conseil n°3 : lancez-vous !

Ne perdez pas un temps considérable à choisir le projet idéal. Si vous connaissez un projet ou une organisation dont la communauté accueille amicalement les débutants, faites-en votre point de départ.

Trouvez un problème avec lequel vous êtes à l’aise, de préférence dans un langage que vous pratiquez déjà depuis un moment, et essayez d’imaginer ce qui a besoin d’être fait. Demandez des informations pertinentes afin de combler vos lacunes, et après, lancez-vous ! N’attendez pas.

Merci à tous ceux qui travaillent dans l’open source

Une dédicace spéciale à tous les contributeurs aux projets open source qui sont super réactifs et qui encouragent les nouveaux. Vous aidez les nouveaux venus à se frayer un chemin au milieu d’interminables lignes de code et les faites contribuer de manière peut-être limitée mais néanmoins significative. Vos efforts sont nécessaires et sincèrement appréciés.

En tant que débutante et développeuse junior, j’essaie juste de trouver mon chemin dans le vaste et formidable monde de l’informatique. Quelques minutes de votre temps, que ce soit pour me présenter une simple technique de débogage ou pour me montrer comment écrire correctement des tests logiciels, m’aideront, au fil du temps, à devenir une meilleure développeuse.

Vous avez l’expérience et j’ai l’envie insatiable d’apprendre autant que je peux.

Un grand merci à Guido, Kumur McMillan et Luca qui ont été de fabuleux mentors tout au long de ce parcours, ils m’ont suivie à chaque instant et ont répondu à mes diverses questions. J’ai vraiment apprécié le temps et les efforts que vous m’avez consacrés 🙂

Si vous êtes un nouveau venu qui peine à entrer dans le monde de l’open source, j’aimerais que vous me parliez de votre histoire et de votre expérience. Si je peux vous aider de quelque façon que ce soit, surtout n’hésitez pas à me contacter.

J’envisage de rendre compte de mon parcours chez les contributeurs de l’open source, donc si vous désirez que j’aborde un sujet en particulier, merci de laisser un commentaire.
Merci à Pawan Dubey et Quincy Larson pour m’avoir aidée à peaufiner cet article.