CLIC : Un projet pour des apprentissages numériques plus interactifs

La proposition de CLIC est de s’auto-héberger (de faire fonctionner des services web libres sur son propre matériel) et de disposer de ses contenus et données localement, et/ou sur le grand Internet avec un système technique pré-configuré. Le dispositif s’adresse plutôt à des militant⋅es, des chercheur⋅euses, des formateur⋅ices… amené⋅es à se rendre sur le terrain, où la connexion Internet n’est pas toujours stable, voire est inexistante.

Note grammaticale : nous n’avons pas réussi à trancher entre « le CLIC » ou « la CLIC » pour le nom du dispositif, alors en attendant de décider, nous alternons entre les deux tout au long de l’article.

Depuis décembre 2022, un an après une première rencontre, la clique du projet CLIC s’est retrouvée deux fois :

  1. à Paris au CICP et en ligne pour une nouvelle session de travail et d’échange avec des chercheur⋅ses de l’IRD.
  2. à Montpellier au Mas Cobado dans une ambiance de fablab éphémère

À la fin de la session de novembre 2021, l’objectif pour 2022 était d’avoir testé le dispositif dans plusieurs contextes. Des CLICs ont ainsi été mis en place pour les labs d’innovation pédagogique, et pour les territoires d’expérimentation Colibris, des contenus accessibles hors ligne ont été ajoutés avec kiwix.

Une difficulté s’est cependant vite posée, liée à l’état de développement du dispositif : l’installation nécessitait alors un accompagnement humain qui manquait une fois de retour sur le terrain, si la CLIC ne fonctionnait plus. Pour les CLICs livré⋅es clé en main, la maintenance et parfois l’usage lui-même étaient donc dépendants des humain⋅es de la clique. Enfin, la pénurie de nano-ordinateurs comme les Raspberry Pi a empêché de s’approvisionner en matériel à déployer. Le projet a donc peu avancé, mais l’intérêt est resté présent.

Premiers retours d’usage

Une priorité pour les retrouvailles de décembre 2022 a donc été d’identifier la cause des problèmes surgissant à l’installation d’une part, et de rédiger un tutoriel pour accompagner l’installation pour les personnes souhaitant plonger dans le projet d’autre part.

Des premiers retours d’usages des chercheur⋅ses de l’IRD ont permis de soulever plusieurs questions :

  • celle de l’usage d’un logiciel d’enquête non-libre en lien avec un CLIC,
  • celle de la récupération de sauvegarde de ce qui a été travaillé localement en vue de le publier en ligne,
  • celle de la compatibilité avec différentes bases de données.

Sur la question de l’usage de solutions techniques non-libres, le projet CLIC s’appuyant sur YunoHost, rapidement la réponse a été qu’on ne chercherait pas de compatibilité avec de telles solutions, préservant nos ressources pour la recherche sur des solutions libres.

Concernant la récupération « facile » des sauvegardes, la réponse reste à être identifiée et implémentée, car il n’y a pour le moment pas de solution clé en main le permettant, autre que l’outil de sauvegarde intégré à YunoHost. Si l’utilisateur⋅ice peut se passer d’une aide graphique, le transfert vers une autre CLIC ou vers un YesWiki devrait pouvoir se faire sans trop de difficultés.

Pour la compatibilité avec les bases de données, plusieurs sont supportées par le projet CLIC : MariaDB (ou MySQL), PostGreSQL. Pour des solutions personnalisées (par exemple à partir d’openHDS), des installations supplémentaires sont à envisager, mais pas impossibles.

Un ordinateur portable et un téléphone posés sur un bureau encombré de matériel informatique. L'écran du téléphone affiche la page d'installation d'une CLIC, celui de l'ordinateur affiche une illustration pour le portail de services en cours de modification sur Inkscape.
En un CLIC, une installation simplifiée et ergonomique.

 

Les discussions tout au long de 2022 ont mis en évidence un intérêt pour plusieurs cas d’usage :

  • pour un usage pédagogique en classe, en formation (apprendre à administrer un serveur, se former à l’utilisation de logiciels…),
  • pour réaliser un travail de terrain en Sciences Humaines et Sociales (anthropologie, démographie, linguistique, etc.) sans connexion,
  • pour s’affranchir du recours à la 4G en cas de connexion Internet défaillante ou restreinte (réseaux d’université par exemple),
  • pour mettre à disposition des contenus (supports pédagogiques, informations utiles dans un contexte précis, partages au sein d’une communauté…).

Si vous vous retrouvez dans ces cas, ou que vous en identifiez d’autres et que vous souhaitez participer aux tests du prototype du CLIC, contactez-nous sur contact AT projetclic.cc. Nous pouvons vous accompagner dans les premières étapes, et vos retours seront très utiles pour avancer ce projet.

Vous pouvez aussi regarder par vous-même, auquel cas vous aurez besoin :

Des améliorations logicielles et matérielles

Après ces deux rencontres, on compte cinq grosses améliorations :

  • Un site a été créé pour le projet pour y retrouver actus, communauté, images à télécharger et tutoriels : https://projetclic.cc.
  • Le hotspot wifi affiche une popup permettant de retrouver le portail sans connaitre son adresse url d’avance,
  • L’installateur permet de choisir les applications qu’on veut utiliser parmi une sélection,
  • Le portail de sélection de service a été travaillé graphiquement et une démo est disponible,
  • Des images sont mises à disposition pour les modèle de nano-ordinateurs Odroid en plus des RaspberryPi.

Capture d'écran d'une page web avec un message de bienvenue présentant le projet puis plusieurs images dans une rubrique "coopérer". Elles représentent deux personnes habillées en rouge ou en jaune, en action autour de différents tableaux thématiques : prendre des notes à plusieurs, partager des documents, organiser des idées, etc.
Le portail de sélection des services a été travaillé graphiquement.

 

Les améliorations matérielles ne sont pas en reste :

  • Design et impressions 3D de boîtiers pour nano-ordinateur Odroid

Deux boîtiers imprimés en 3D, un rouge et un bleu, indiquant le nom et l'url du projet CLIC.
Des boîtiers pour nano-ordinateurs Odroid.

  • Travail sur la Chatravane avec des ateliers pédagogiques sur la consommation énergétique en autonomie avec des panneaux solaires.

Deux malettes posées l'une devant l'autre. Celle de derrière est noire striée de blanc. Celle de devant est vitrée et laisse voir batterie et câbles.
La chatravane, un prototype de serveur nomade alimenté par des panneaux solaires.

 

Pour la suite, il est prévu :

  • De continuer de travailler sur le système et son installation, notamment pour s’approcher au maximum d’une installation « en un clic ».
  • D’ajouter une facilitation graphique au tutoriel, pour aider à la compréhension du fonctionnement d’une CLIC.
  • De continuer les tests sur le terrain (et adapter la documentation en fonction des observations).
  • De prévoir un hackathon axé sur le design et la communication.

Le projet CLIC avance doucement mais sûrement, grâce à du temps de travail bénévole et rémunéré (ritimo, Mouvement Colibris, YunoHost) et au soutien de Framasoft.

Nos prochaines retrouvailles seront aux Journées du Logicel Libre (JDLL) les 1er et 2 avril 2023, où vous nous retrouverez en déambulation et de manière plus posée, au stand de nos ami·es de YunoHost.

Crédit photos : 12b Fabrice Bellamy et Mathieu Wostyn
Crédit vidéo : Mouvement Colibris
Licence CC BY SA




CLIC ! : une plateforme de coopération tout terrain

Fin novembre, des commoners (militant·e·s des communs), artistes, animateurs et animatrices de rues se sont retrouvé·e·s au Vigan (dans les Cévennes gardoises), pour travailler sur le #ProjetCLIC! (Contenus et Logiciels pour des Internets Conviviaux !), une plateforme numérique pour essaimer des pratiques numériques et coopératives, solidaires et émancipatrices grâce à des logiciels, ressources et formations librement partageables.


Que ce soit dans le secteur associatif, en entreprise, ou dans tout autre collectif, les besoins en outillage informatique sont prégnants. Les géants de l’Internet savent proposer des solutions qui paraissent convenir mais cela a un certain prix, que ce soit en termes monétaires ou d’abandon de notre vie privée. Heureusement, certaines initiatives, telles que celles portées par Framasoft et les CHATONS, permettent de répondre à ces besoins sans concession. Cependant, ces solutions nous font dépendre de tiers, qui doivent être de confiance, et elles sont limitées à la présence d’une connexion internet et à la capacité du tiers à maintenir son service en ligne. En outre, ces outils sont livrés « nus » : il nous faut alors les alimenter en contenus afin de partager nos savoirs et connaissances.

Comment permettre que ces contenus et outils soient facilement accessibles, utilisés et réutilisables dans tous les contextes, y compris les plus éloignés de l’Internet ?

C’est à cette fin que les Animacoop, Colibris, Framasoft, ritimo, le Réseau national des ressourceries, Yunohost et autres allié·es ont imaginé « CLIC! », pour essaimer des pratiques numériques coopératives, solidaires et émancipatrices.

La proposition de CLIC! est de s’auto-héberger (d’installer les services sur son matériel, chez soi) et d’avoir ses outils libres et contenus disponibles localement, et/ou sur le grand Internet avec un système technique pré-configuré. On vous explique.

CLIC! home servicesL’interface de sélection des services dans CLIC!

Entre Chatons et PirateBox : CLIC!

CLIC! pourrait être vu comme un mix entre un CHATONS (hébergeur de logiciel et service libre) et une Piratebox (dispositif électronique accessible par wifi, permettant de partager des contenus libres) pour mettre l’auto-hébergement à la portée de toutes et tous.

Coté logiciel, CLIC! est une distribution Linux issue de Yunohost qui propose déjà des services et des contenus libres préinstallés. L’idée est de proposer en plus des contenus thématiques installables en un clic (fichiers multimédias, parcours pédagogiques, …)

Coté matériel, il pourrait s’installer sur différentes machines: le gros serveur dans un datacenter, un nano-ordinateur type Raspberry Pi, ou encore sur des « ordinosaures » (de vieilles tours d’ordinateurs ou d’anciens ordinateurs portables réutilisés).

Dessin CLIC! FrédériqueUn schéma de Frédérique pour y voir plus clair (ou pas)

Une coding party pour faire avancer le projet

La semaine du 22 au 28 novembre 2021, un groupe éclectique de développeur·euses, facilitateur·rices, bricoleur·euses et artistes issu·es de divers horizons se sont retrouvé·es pour imaginer des usages, adapter l’ergonomie, travailler l’interface, réaliser des installations artistiques dans l’espace public et poursuivre les développements de la distribution CLIC!

Le groupe s’est retrouvé à la Fabrègue (la fabrique en occitan), un écolieu du Vigan associé à la ressourcerie locale.

Une vidéo timelapse pour voir l’ambiance et comment on collaborait

Appréhender ce que pourrait être un Internet low-tech

Qu’est-ce qu’un Internet low-tech ? Le simple fait de trouver une définition des concepts et de se mettre d’accord sur le degré d’autonomie souhaité est un vaste sujet !
De nombreuses personnes réfléchissent déjà au sujet. Notre approche est très concrète : comment faire du mieux avec les ressources à disposition près de chez nous (récupérer du vieux matos dans ses placards ou dans les ressourceries) et tester du matériel peu gourmand en énergie (comme un nano-ordinateur) pour s’auto-alimenter en électricité.
Voici les pistes explorées durant cette semaine au Vigan :

Alimentation autonome via panneaux solaires

Quelques tests ont été réalisés pour discuter des problématiques d’alimentation d’un petit ordinateur ARM avec une batterie lithium et un panneau solaire USB.

Une caractéristique importante des batteries est la puissance maximale qu’elles peuvent absorber quand on les charge. C’est ce qui permettra de déterminer s’il est possible de les recharger en une seule journée via un panneau solaire ou s’il faudra compter plusieurs jours de soleil pour une charge complète.

12b prend des mesures d’un Raspberry Pi sur batterie, avec un écran portable branché.

Toutes les informations à ce sujet sur https://wiki.distrilab.fr/?TestsBatteriesEtPanneauxSolairesUSB

Récupération de batteries lithium d’anciens ordinateurs portables

Un beau travail a été mené pour détailler les opérations nécessaires pour récupérer des batteries depuis des vieilles batteries d’ordinateurs portables. Toutes les opérations sont détaillées dans un tutoriel accessible sur le wiki du Distrilab.

Alimentation et batterie lithiumLes piles lithium rondes que l’on peut trouver dans les batteries d’ordinateurs portables

Réemploi de vieux ordinateurs (ordinosaures)

Visite à la Ressources du pont au ViganLa délégation partie faire ses courses à la Ressourcerie du Pont pour faire le plein d’ordinosaures qui deviendront autant de kiosques autonomes mettant à disposition autant de services numériques que des livres électroniques ou des MOOCs

Hack-design

Des plasticien·nes locaux ont fait parler leur imagination pour créer de nouveaux looks pour différents usages :

  • Yeahman : un crieur de rue qui enregistrera des paroles publiques et les rediffusera, faisant office de jukebox actionnable par liens mp3 dans des QR-codes
  • Mouche à facette: un Raspberry Pi volant, avec des ailes en boule à facettes
  • Girafe rose : une statue de girafe en bois cachant un point d’accès wifi et un serveur CLIC!

Raspberry pi zero avec écran e-inkAutre piste explorée : un lecteur d’annonces connecté au web par flux RSS, à base de raspberry pi zéro et écran e-ink (comme sur les liseuses d’e-book, l’écran noir et blanc continue d’afficher du contenu sans avoir besoin d’énergie)

Améliorer les outils pour permettre l’usage en local et déconnecté du grand internet

Nous avons profité de la présence d’éminents contributeur·ices Yunohost et Chatons, pour contribuer au code de projets libres. Ainsi :

  • Ljf a pu corriger des bugs du hotspot wifi dans Yunohost et faire en sorte qu’il propose les services du serveur CLIC même sans connexion internet ✨
  • Tobias a ajouté le support de Framemo dans le dépot d’applications de YunoHost. Il a également travaillé sur une app permettant de remonter des informations vers l’outil de statistiques des chatons
  • 12b a créé des images Raspberry Pi et Odroid « clé en main » pour avoir un Yunohost avec des services installés, et une sélection de contenus de formations, de vidéos et de textes préinstallés, et accessibles en mode wifi « hotspot » local.
  • Aleks a fait une interface de configuration initiale pour CLIC!, accessible depuis le navigateur web, basée sur ce qui existait déjà pour la brique internet.

Ordinateur qui lance l'install de CLIC!L’interface d’installation de CLIC!

Penser les usages et les contenus pour être au plus proche des besoins des gens

Le temps nous a manqué pour réaliser tout ce que nous avions imaginé, en partie parce que nous avons pris du temps pour avoir des moments de restitution et d’échange avec les personnes en visite sur le lieu, ce qui fut riche !
Des graines de projets ont donc été semées et pousseront en 2022 :

  • une rubrique « Participation citoyenne » est apparue dans CLIC!, pour permettre d’effectuer des votes, des sondages et d’autres échanges locaux ;
  • initier les bénévoles de la ressourcerie à l’installation de ces kiosques sur des vieux ordinateurs et mettre la formation à disposition de toutes et tous ;
  • faire des tests utilisateur·ices en direct sur un marché avec un nano-ordi nomade et un kiosque à la ressourcerie.

Affiche OrdinosaureUne affiche de présentation des bornes Recy’clic par Uto de R(d)évolution

Expérimenter de nouvelles manières de travailler ensemble

Se voir en vrai, vivre ensemble, prendre soin des besoins de toutes et tous, s’amuser, passer du bon temps entre et avec des personnes inspirant·es… Cette rencontre a provoqué une envie de continuer à travailler ensemble sur ce projet. Voici quelques ingrédients, que nous pouvons partager, pour des rencontres réussies :

  • Liberté de rythme et de présence : certains étaient là pour quelques jours, d’autres pour une semaine. Certains actifs tôt le matin, d’autres (et iels étaient nombreux⋅ses) tard dans la nuit.
  • Un lieu inspirant et des hôtes accueillant·e·s, merci R(d)évolution du Vigan!
  • Un cadre de travail mêlant grand repas auto-organisés, discussions enflammées, temps de travail collectif et présentation croisées des avancées
  • Des animateur·ice·s soucieux·ses de l’inclusion des participant·es, de nombreux points de synchronisation
  • Faire du commun, trouver du sens dans nos collaborations

Quelques liens pour creuser

Le mot de la fin

Comme d’habitude sur le framablog, un petit mot des participant·es pour conclure :

  • ljf : Il reste de nombreux défis à relever pour proposer de l’auto-hébergement facile, itinérant et déconnectable, cette résidence était un pas de plus, longue vie au projet CLIC! et merci aux habitant⋅es de la Fabrègue et à leur énergie inspirante.
  • 12b : De belles rencontres et un projet inspirant. On continue en 2022!
  • Simon : Une chouette rencontre avec une belle diversité et plein d’idées, vivement la suite !
  • Tobias : Une rencontre hors du temps qui crée autant de code que d’idées et de liens entre les personnes.
  • Frédéric : Une belle parenthèse pour moi qui cours toujours après le temps et de super rencontres! Ce fut un vrai moment de bonheur de pouvoir participer au développement de cette solution. Merci à tous·tes
  • Christian : un chouette moment d’échange, pour découvrir, expérimenter, tester et discuter. Un grand merci aux organisateurs.
  • Lilian : Il y a encore du travail pour que cela soit accessible à tous·tes, mais un énorme potentiel pour permettre à chacun·e d’avoir facilement accès à des outils éthiques.
  • Ulysse : Une très belle aventure, qui va essaimer, et pas forcément là où on l’imagine, et c’est ça qui est beau !
  • Florian: merci Framasoft de nous avoir soutenus dans cette démarche et au plaisir de vous voir à notre prochain sprint IRL avec ce super groupe <3
  • Mathieu : un dispositif dont ritimo rêvait depuis de nombreuses années, qui est en train d’aboutir avec les précieuses contributions de chouettes personnes, et un soutien extra de Framasoft : la recette pour créer du lien, de l’interconnaissance, de la confiance – et construire ensemble du commun !

Crédit photos et vidéos : 12b Fabrice Bellamy – licence CC BY SA




J’enseigne, je code et je partage : une série de portraits-entretiens à la rencontre des enseignant⋅es développeur·euses

J’enseigne, je code et je partage est une série de portraits-entretiens à la rencontre des enseignant⋅es développeur·euses réalisée par Hervé Baronnet (enseignant) et Jean-Marc Adolphe (journaliste culture et humanités) pour l’association Faire École Ensemble. Déjà 3 de ces portraits-entretiens ont été publiés et on s’est dit que ça pourrait être chouette d’en savoir un peu plus sur cette initiative. Alors, on a demandé aux interviewers s’ils acceptaient d’être interviewés à leur tour.

Bonjour Hervé et Jean-Marc ! Pouvez-vous vous présenter ?

Bonjour,
Hervé Baronnet, je suis enseignant en maternelle depuis 25 ans, toujours en zone d’éducation prioritaire. Utilisateurs des TICE, notamment de logiciels éducatifs libres mais pas exclusivement. J’ai contribué au projet AbulÉdu en tant que bêta-testeur et auteur de documentations pédagogiques. Je suis actuellement membre du conseil collégial de FÉE.

Bonjour,
Jean-Marc Adolphe, journaliste et conseiller artistique, ex-militant FCPE. Je m’intéresse depuis longtemps à l’éducation aux médias, à mes yeux insuffisamment enseignée à l’école. Et en tant que citoyen, l’école m’engage. La question des « biens communs numériques » me semble essentielle dans tout ce qui ressort du service public, particulièrement au sein de l’Éducation nationale.

Vous êtes tous les deux adhérents de l’association Faire École Ensemble. C’est quoi cette asso ?

L’association Faire École Ensemble est une association collégiale qui facilite les collaborations entre les citoyens et la communauté éducative tout au long de la pandémie. Fée engage des projets collaboratifs en s’appuyant sur 3 spécificités : la convivialité, la documentation et le recours par défaut aux licences ouvertes.

Concrètement, à l’annonce de la fermeture des écoles et de la mise en place généralisée de l’enseignement à distance en mars 2020, nous avons mobilisé 1000 citoyennes et citoyens pour aider les professeurs peu à l’aise avec le numérique. S’en sont suivies d’autres actions autour de la réouverture progressive des écoles avec un protocole sanitaire drastique, les possibilités de faire école à l’extérieur, la préparation d’une rentrée apaisée en passant une nuit à l’école et une action réflexive sur la place du numérique dans l’enseignement (recherche-action ; états généraux du numérique libre et des communs pédagogiques).

Ce que nous faisons avec Faire École Ensemble relève d’une configuration tiers-lieux telle que définie par Antoine Burret (« le tiers-lieu peut-être défini conceptuellement comme : une configuration sociale où la rencontre entre des entités individuées engage intentionnellement à la conception de représentations communes »). Nos projets réunissent des communautés de personnes diverses (parents, profs, designers, chercheurs, élèves, architectes, juristes, militants associatifs, artistes…) autour d’une intention commune (réaménager sa classe, organiser une nuit à l’école, penser la pédagogique en période de crise…). Nous documentons les conversations (formelles et informelles) pour faire émerger un patrimoine informationnel commun, nous prenons soin des liens entre les personnes, sommes garants de la convivialité et accompagnons celles et ceux qui le souhaitent dans le passage à l’action (nous ne faisons pas à leur place).

J’ai cru comprendre que FÉE souhaitait développer une communauté d’enseignant⋅es développeur·euses en informatique. Quel est l’objectif ? Ça s’organise où et comment ? Quelles sont les modalités pour y participer ?

La création de la communauté d’enseignant⋅es développeur·euses s’inscrit dans le cadre du programme sur le libre et les communs dans l’éducation. Cette action fait suite aux États Généraux du Numérique Libre et des Communs Pédagogiques et vise à réunir les enseignant⋅es développeur·euses en communauté pour penser/agir en faveur d’un numérique éducatif plus coopératif et plus éthique.

C’est une communauté ouverte pour :

  • Comprendre quelles sont les spécificités des enseignant⋅es développeur·euses et favoriser leur mise en visibilité
  • Promouvoir leurs projets de développement
  • Faciliter les contributions et favoriser l’entraide

La communauté s’organise autour d’une catégorie sur le forum de FÉE où l’inscription est libre, et d’une page sur le wiki de FÉE.

Des webinaires « le logiciel libre par des acteurs de l’éducation pour l’éducation » dans le cadre du cycle sur le libre et les communs sont proposés régulièrement. Les enseignant⋅es développeur·euses sont invité⋅es à y participer.

Il est important de souligner que les « enseignant⋅es développeur·euses » ne sont pas nécessairement des spécialistes en informatique. Ce sont avant tout des enseignant⋅es, soucieu⋅ses de trouver des ressources pédagogiques et « techniques » adaptées à leurs élèves.

Dans ce cadre, vous vous êtes lancés dans une série d’interviews d’enseignant⋅es développeur·euses. Quel est l’objectif de ces interviews ?

Le premier objectif de cette série d’entretiens-portraits est de faire connaître l’existence de ces personnes, de les valoriser elleux ainsi que les projets sur lesquels ielles travaillent. Ensuite, un portrait type présentant leurs spécificités va pouvoir naître en croisant les réponses.

Carte heuristique pour mettre en évidence les spécificités des enseignant⋅es développeur·euses.

Il s’agit de faire savoir à d’autres enseignant⋅es développeur·euses qu’ielles ne sont pas seul⋅es. À plus long terme, il s’agit de faire prendre conscience de la valeur de ces acteur⋅ices et de lister les freins et les besoins pour aboutir à un soutien institutionnel.

Sur quels critères sélectionnez-vous les enseignant⋅es développeur·euses pour votre série de portraits ?

Nous avons sollicité dans un premier temps des enseignant⋅es qui s’étaient inscrit⋅es sur le forum de FÉE. Puis nous avons réalisé des portraits de personnes au profil plus étendu, avec la double casquette enseignant et développeur au sens large. Le fait de développer ou de contribuer à des logiciels libres est privilégié dans le choix des entretiens.

#ModeTroll : il y a à ce jour 3 entretiens sur le blog et uniquement des hommes. C’est volontaire de ne pas valoriser la gent féminine ?

Il y en a 3 et bientôt 6, tous des hommes, en effet ! FÉE n’y est pour rien (le conseil collégial de l’association devrait être bientôt à parité hommes / femmes). Il se trouve que seuls des enseignants-hommes se sont manifestés à ce jour. Mais nous profitons de cet entretien pour lancer un appel à des enseignantes-développeuses afin qu’elles participent à cette série d’entretiens et qu’elles puissent rejoindre la communauté qui est en train de se former.

Quelle est la place du logiciel libre dans les pratiques des enseignant⋅es développeur·euses ?

La place du logiciel libre est centrale, car la priorité a été donnée aux enseignant⋅es développeur·euses libristes, cette action étant dans la continuité des États Généraux du Numérique Libre organisés par FÉE.

Des développeur·euses qui utilisent des outils non libres ou développant des applications gratuites propriétaires pourront aussi être sollicité⋅es pour mieux définir ce qui les empêche de basculer vers le libre.

Et comme toujours, sur le Framablog, on vous laisse le mot de la fin !

À partir de ces entretiens des caractéristiques communes aux enseignant⋅es développeur·euses peuvent être extraites.

Parmi les points positifs :
+ la motivation à aider les élèves
+ l’éthique comme moteur
+ la valeur ajoutée de leur projet en tant qu’outil métier

Parmi les aspects négatifs :
– le temps, la non-reconnaissance du travail
– le code « amateur » peu ou pas documenté
– l’aspect chronophage des questions des utilisateur⋅ices qui augmente avec le succès des logiciels

Notre contributopie serait de limiter ces freins par l’impulsion de solutions :

  • Que les institutions qui emploient ces enseignant⋅es développeur·euses reconnaissent l’intérêt de leur travail et leur permettent d’y consacrer du temps. Les enseignant⋅es ne veulent pas devenir développeur·euses à temps plein, le côté passion est leur moteur et les expériences de « professionnalisation » ont été des échecs.
  • Que la communauté du libre les aide pour améliorer le code sous forme, par exemple, de formations menées par des développeur·euses professionnel⋅les.
  • La mise en place d’une communauté d’usage permettant de répondre aux questions des utilisateur⋅ices et de créer de la documentation pédagogique.

Merci beaucoup pour vos précisions Hervé et Jean-Marc. Et on espère que de nombreu⋅ses enseignant⋅es et libristes rejoindront votre communauté.




You are invited to contribute to the future « Contributing to Free-Libre Open Source Software » MOOC by Télécom Paris and Framasoft

Interested in contributing to the contents production of a MOOC about FLOSS contribution? You already have a contribution experience and think it can be useful to new contributors? Join us!

The French original version of this article has been published on this blog on Feb. 4th, 2021.

Leading Internet users into the world of contribution

Last September we were so delighted to learn that Marc Jeanmougin, a research engineer at Télécom Paris, wanted Framasoft to be associated with his online course projet on FLOSS contributions that had just been funded by the Institut Mines-Télécom.

We have been dreaming about it: a MOOC to learn how to contribute to free-libre software

Developing digital tools that facilitate individuals’ contributions is one of the lines of our Contributopia campaign. On this subject we already have set up Contribateliers (and their online version Confinateliers): workshops to discover how each of us can contribute to free-libre software. Implemented in 2018 in Lyon, those interventions now take place in cities (Lyon, Paris, Toulouse, Grenoble and Nantes) allowing people to contribute to the free-libre software and free culture in a user-friendly way.

This is also the case with the Contribulle project we are hosting: a platform where projects with the same free-libre software values are connected with those without enough skills and contributors who could give them a hand. This nice initiative is slowly taking shape and we think it will be a great success in the coming months.

Finally, the aim with this Contributing to FLOSS MOOC is to allow developers to get both a theoretical (what is it about?) and practical introduction (how to contact somebody? and how to contribute?) to the world of FLOSS contribution.

All these initiatives allow users of free-libre services to learn how to contribute and to stop using a software only as if it were a finished product.

Contributing to develop the Contributing to FLOSS MOOC

After a first day in October, talking about pedagogical sequencing in a small committee, the prefiguration team decided that given the MOOC subject, it would not be totally far-fetched to allow people who want to co-produce contents with us to do so.

That’s why we have created a project on the Gitlab software forge. For now, few contents have been published on this contribution space. But you can still read the general outline of this future course.

The README.md of the GitLab project

We also have created a dedicated Matrix chatroom in order to have a daily and more informal exchange with you. Do not hesitate to join us there to learn more about this project.

We invite you to exchange in video conference on this project on February, 10th at 6:30pm. At the same time we will present you the general organization of the MOOC and the choices we have made both educationally (what angle on FLOSS we will try to take) and technically. We will also discuss how we envisage contributions to contents production.

If after this first exchange you want to help us with contents preparation, you can participate in 6 other online brainstorming sessions, each one dedicated to the contents of one week of the MOOC. They will take place on Mondays and Thursdays between 6:30pm and 8pm from February 11th to March 1st (details of access and contents will be published on the gitlab issues with each session).

GitLab issues with details of access and contents of the 6 meetings we offer.

We hope we will see many of you at those different events. But as we know it’s not always easy to be available on a set time slot, we offer to collect your reactions, feedbacks or comments before each session on our repository. Do not hesitate to write down whatever comes to your mind!




Télécom Paris et Framasoft vous invitent à contribuer au futur MOOC « Contributing to Free-Libre and Open Source Software »

Participer à la production des contenus d’un MOOC dont le sujet est la contribution aux logiciels libres, ça vous tente ? Vous avez déjà contribué à des logiciels libres et vous pensez que votre expérience peut aider des apprenti·es contributeur·ices ? Rejoignez-nous !

Découvrez la version en anglais de cet article réalisée par notre stagiaire Coraline.

Continuer à accompagner les internautes dans l’univers de la contribution

Lorsqu’en septembre dernier, Marc Jeanmougin, ingénieur de recherche à Télécom Paris, nous contactait pour nous informer que son projet de cours en ligne sur la contribution au logiciel libre venait d’obtenir un financement de l’Institut Mines-Télécom et qu’il souhaitait que Framasoft soit associé à ce projet, on a été super emballé·es !

Un MOOC (cours en ligne massivement ouvert) pour apprendre à contribuer au logiciel libre, on en rêvait !

C’est d’ailleurs l’un des axes de notre campagne Contributopia que de concrétiser des outils numériques qui facilitent les contributions de chacun·e. Dans ce domaine, nous avons déjà initié les Contribateliers (et leur version en ligne, les Confinateliers), des ateliers pour découvrir comment chacun·e d’entre nous peut contribuer au logiciel libre. Lancé en 2018 à Lyon, ce dispositif existe désormais dans 5 villes (Lyon, Paris, Toulouse, Grenoble et Nantes) et permet à toutes et tous de contribuer aux logiciels libres et à la culture libre en toute convivialité.

C’est aussi ce que nous faisons en offrant un hébergement au projet Contribulle, une plateforme de mise en relation entre des projets partageant les valeurs du logiciel libre et des communs qui manquent de compétences, et des contributeur·rices qui pourraient leur donner un coup de main. Cette chouette initiative prend doucement forme et on ne doute pas qu’elle rencontrera un fort succès dans les mois à venir.

Enfin, avec ce MOOC Contributing to FLOSS, l’objectif est de permettre à des développeur·euses d’avoir une introduction théorique (de quoi parle-t-on ?) comme pratique (comment entrer en contact, comment contribuer ?) à l’univers de la contribution au libre.

Toutes ces initiatives sont l’occasion pour les utilisateur·ices de services libres d’apprendre à contribuer et d’arrêter de consommer simplement le logiciel comme s’il était un produit fini.

Contribuer à la réalisation du MOOC Contributing to FLOSS

Après une première journée en petit comité en octobre pour échanger sur le séquençage pédagogique, l’équipe de préfiguration s’est dit que vu le sujet du MOOC, ce ne serait pas totalement tiré par les cheveux que de permettre à celles et ceux qui le souhaitent de co-produire avec nous les contenus.

Pour cela, un projet a été créé sur la forge logicielle Gitlab. Pour le moment, peu de contenus ont été publiés sur cet espace de contribution. Mais vous pouvez tout de même prendre connaissance du plan général de ce futur cours.

Le README.md du projet sur GitLab

Nous avons aussi créé un salon Matrix dédié afin de pouvoir échanger de manière plus informelle avec vous au quotidien. N’hésitez pas à nous y rejoindre pour avoir davantage de précisions sur ce projet.

Nous vous invitons à un temps d’échanges autour du projet le mercredi 10 février à 18h30 en visioconférence. Ce sera l’occasion de vous présenter l’organisation générale du MOOC et les choix que nous avons effectués, tant au plan pédagogique (quel angle sur les FLOSS nous essaierons de prendre) qu’au plan technique. Nous échangerons aussi sur la façon dont nous envisageons les contributions à la production des contenus.

Si à la suite de ce premier temps d’échanges, vous êtes partant·es pour nous aider sur la préparation des contenus, on vous propose de participer à 6 autres sessions de brainstorming en ligne, chacune de ces sessions étant dédiée aux contenus d’une semaine du MOOC. Ces sessions se tiendront les lundis et jeudis entre 18h30 et 20h sur la période du 11 février au 1er mars (les détails d’accès et des contenus discutés seront publiés sur les tickets associés à chaque session).

Tickets sur lesquels vous trouverez détails d’accès et contenus des 6 rendez-vous que nous vous proposons.

On vous espère nombreu·ses lors de ces différents rendez-vous. Mais comme nous savons qu’il n’est pas toujours évident de se libérer sur un créneau fixe, nous proposons de recueillir en amont de chaque session vos réactions, notes ou commentaires. N’hésitez donc pas à aller y noter ce qui vous passe par la tête !




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 !