Pour Framaspace, Framasoft a fait développer un outil de supervision de sites web nommé Argos Panoptès (ou juste Argos pour aller plus vite).
Développé par Alexis Métaireau, développeur entre autres du générateur de site statique Pelican, et de l’outil de gestion de dépenses à plusieurs « I Hate money » (repris dans l’app cospend sur Nextcloud), le besoin a été défini par Luc Didry, l’administrateur système de Framasoft.
Luc et Alexis répondent à nos questions dans cet interview, pour plus d’information concernant Argos vous pouvez consulter l’article dédié.
Bonjour à tous les deux 🙂 Ici on connaît déjà Luc puisque c’est notre admin sys préféré, mais Alexis, peux-tu nous dire qui tu es pour le framablog ?
Alexis : Bonjour, Framasoft, et merci pour la discussion ! Et bien, c’est parti pour l’exercice de la présentation alors.
Je suis un développeur de bientôt 40 ans, intéressé par les dynamiques collectives, le logiciel libre et la protection des données personnelles, depuis quelques années maintenant. Par le passé j’ai pu publier et maintenir quelques outils comme Pelican, un générateur de sites statiques et I hate money, pour gérer les dépenses partagées. J’ai travaillé quelques années pour Mozilla sur la partie synchronisation et chiffrement des données (Firefox Sync, Kinto) et sur quelques autres outils.
J’ai quitté le développement « pro » entre 2018 et 2023. Durant ces années j’ai eu la chance / le privilège de pouvoir monter une brasserie sur Rennes avec un ami. Nous avons essayé de faire vivre les valeurs de la collaboration (plutôt que celles de la compétition). Cela est resté très proche des valeurs du logiciel libre, nos recettes et les plans de nos machines étant par exemple publiés sur notre site web.
À l’été 2023 j’ai décidé de quitter la brasserie pour à la fois refaire du développement et travailler sur les outils de la prise de décision collective, et la gestion des conflits dans les collectifs. C’est à ce moment que nous sommes rentrés en contact avec Luc pour travailler sur Argos.
Pouvez-vous nous présenter l’outil Argos sur lequel vous avez travaillé ? À quel besoin répond-il pour Framaspace ?
Alexis : Argos est un outil de supervision de sites web. L’idée est assez simple: surveiller que les sites vont bien, et générer des alertes quand c’est utile, en envoyant des notifications par email ou autre.
La spécificité d’Argos est de pouvoir gérer un nombre de sites important. Framaspace, en grossissant, expose pas loin de 900 domaines au public, qui parfois tombent en panne. Je crois que le réel besoin derrière Argos était de simplifier la vie de Luc (vous saviez qu’il n’y avait qu’un seul adminsys chez Framasoft ?!!) et de lui permettre d’avoir une meilleure vision globale de l’état du service.
Les vérifications concernent les statuts du site web, mais aussi l’état des certificats SSL, par exemple, et quelques vérifications spécifiques.
Luc : On surveillait déjà plus de 200 sites via notre outil de supervision (Shinken), mais celui-ci, avec toutes les autres sondes de supervision de notre infrastructure, avait bien de la peine à repasser toutes les 5 minutes sur les sites. Ce qui faisait qu’on pouvait se rendre compte qu’un site était tombé au bout de trop de temps.
Avec Framaspace, je savais que j’aurai des centaines (et à terme des milliers) de sites à surveiller en plus, sachant qu’un site est la cible de plusieurs vérifications, comme dit par Alexis. Il fallait donc un outil dédié.
Les outils existants comme statping-ng ou Uptime Kuma présentent un défaut rédhibitoire : vouloir afficher l’état de chaque site en même temps sur l’interface web. Ça va bien quand on a quelques sites, pas quand on en a des centaines (l’outil peine à envoyer les données de centaines de sites).
C’est de là qu’est née l’idée d’Argos, qui a le bon goût de n’afficher qu’un résumé de l’état des sites par défaut.
Capture d’écran de la page de statut d’Argos
Si on regarde de plus près les coutures, on voit que c’est développé en langage Python avec une base de données en PostgreSQL. Laissez-moi deviner : Alexis a choisi Python et Luc a choisi PostgreSQL ?
Alexis : Ah, je vois que tu nous connais un peu, mais figure toi que même pas ! J’aurais aimé plaider coupable pour le coup, mais Luc cherchait spécifiquement quelqu’un qui savait faire du Python, et c’est comme ça qu’on s’est rencontré. J’ai proposé d’utiliser le framework FastAPI à la place de Flask parce que ça nous permettait de faire de l’asynchrone de manière plus simple, et d’utiliser les fonctionnalités de typage de Python.
Luc : Pour Framaspace, j’ai été plus ou moins obligé de faire du Python car Salt, l’orchestrateur utilisé pour déployer les espaces est en Python : je pouvais, en utilisant ce langage, l’utiliser comme une bibliothèque, sans utiliser de bidouilles sales.
Comme Argos a été créé dans le cadre de Framaspace, j’ai voulu garder le même langage de programmation, pour avoir un tout cohérent.
Python n’est pas un langage si pire que ça. Il n’est pas amusant, mais ça fait le job. Peut-être aussi que je vieillis : j’utilise de plus en plus Python pour des scripts. Peut-être qu’écrire des scripts ne m’amuse plus, et que je veux les écrire vite pour passer à autre chose.
La question habituelle de libriste : pourquoi avez-vous choisi de développer un outil dédié, il n’existait pas d’outils libres pour de la supervision ? Quelles sont ses spécificités ?
Alexis : Je te laisse répondre Luc, c’est toi qui a affiné le besoin 🙂
Luc : Ah bah zut, j’ai déjà répondu au-dessus 😅
L’avantage d’avoir notre propre outil nous permet aussi de le tordre pour nos besoins spécifiques. Ainsi Argos envoie-t-il des notifications à notre serveur Gotify. Intégrer un tel canal de communication dans un outil existant aurait pu prendre du temps (comprendre le code, faire une PR, attendre une release…).
En lisant la doc, ça a l’air tout simple à utiliser par rapport à d’autres outils !! Comme administrateur⋅ice système du dimanche après-midi, si je veux surveiller l’état de mes sites, est-ce qu’il y a des pièges ou des choses à savoir ?
Alexis : Je pense que ça pourrait tout à fait permettre de surveiller l’état de quelques sites, bien que peut-être surdimensionné. Argos a besoin de lancer un serveur, une base de données et des agents. Est-ce bien utile pour un⋅e adminSys du dimanche ? Peut-être !
Luc : Franchement, je pense qu’il peut être utilisé aussi bien par une grosse organisation que par un·e adminSys du dimanche. La configuration est simple, l’installation pas très compliquée, et il n’a pas l’air de consommer beaucoup de ressources.
Alexis tu étais en mode prestation pour développer, comment s’est passée la relation avec Framasoft ?
Alexis : Franchement, c’était une surprise totale, et un plaisir du début à la fin. On a d’abord pu se faire quelques appels avec Luc pour clarifier les besoins, je me suis retrouvé avec une liste de fonctionnalités de base, et j’ai avancé comme ça.
Quand j’avais besoin j’ai pu échanger avec Luc qui était toujours assez réactif, et j’ai pu lever quelques blocages. J’ai beaucoup apprécié répondre à un besoin concret, en ayant l’utilisateur final au bout du fil pour clarifier les choses.
Par la suite, on a pu se faire quelques sessions ensemble, à la fois de présentation de l’outil, puis de pair-programming pour accompagner Luc sur certains aspects quand c’était utile, l’idée étant que ce soit lui qui prenne la main sur le projet.
C’était en fait ma première mission en tant que « prestataire », je crois que je suis très bien tombé !
Luc : Pareil de mon côté, c’était très agréable de bosser avec toi !
Est-ce que vous pensez que ça peut être utilisé dans d’autres contextes que Framaspace ?
Alexis : je pense que ça peut être utilisé dans d’autres contextes bien sûr. Je pense aux « fermes de sites », comme par exemple ce que peut faire NoBlogs en Allemagne, mais de manière générale c’est utile d’avoir un outil simple d’accès pour faire de la supervision. Bosser là-dessus m’a donné envie de permettre de faire de la supervision « en tant que service », pour des collectifs pour qui ce serait utile, mais… j’imagine que c’est une autre histoire.
Luc : Carrément ! Pas seulement pour des fermes de sites mais partout où on a besoin d’une supervision qui passe très régulièrement. On peut avoir des vérifications effectuées toutes les minutes, ce qui peut être utile sur des sites qui ne doivent pas tomber. Et un grand nombre de sites ne devrait pas faire peur à Argos : on peut multiplier le nombre d’agents (le logiciel qui s’occupe d’effectuer les vérifications et d’en remonter le résultat au serveur), et le choix de PostgreSQL comme base de données a (aussi) été fait parce que c’est un SGBD robuste qui peut encaisser de la charge de travail.
Et est-ce que vous imaginez une suite, avec une feuille de route ou des invitations à contribuer ?
Luc : Il y a déjà des idées de développements futurs pour améliorer Argos, mais ça n’est pas urgent : la première version est déjà tout à fait fonctionnelle.
Alexis : J’aime bien l’idée de ne pas avoir de feuille de route trop précise pour le futur, ce qui nous permet de se concentrer sur des besoins réels et de ne pas en faire une usine à gaz. Si vous l’utilisez et que vous avez des retours à faire, ou bien si vous souhaitez contribuer, n’hésitez pas. C’est pensé pour être simple à étendre, donc n’hésitez pas à jeter un œil et à proposer des changements.
Si vous avez encore des choses à dire 🙂
Alexis : Coucou Numahell, chouette de te recroiser par ici après ces quelques années 🙂
Luc : Merci à toi, Alexis, pour le temps bénévole que tu as consacré à Argos après ta prestation !
Argos Panoptès : la supervision de sites web simple et efficace
Un nouvel outil de supervision de sites web vient de sortir de la forge de Framasoft, tout beau, tout neuf, tout simple. Mais pourquoi ? On vous explique tout !
Le problème
Chez Framasoft, nous avons beaucoup de sites web. Vous connaissez les adresses de nos services, https://framacarte.org pour Framacarte, https://framapad.org pour les pads, etc.
Mais il y en a bien plus sous le manteau : nos outils associatifs (un Nextcloud, un Odoo, des wikis…), les versions de test des services (soit pour tester un nouvel outil, soit pour vérifier que la mise à jour se passera bien…), les sites des amis qu’on héberge (coucou Grisebouille, Affordance et les autres 👋), etc.
Comme je (nda : Luc) suis quelqu’un de plutôt méticuleux, tous nos sites sont supervisés, c’est-à-dire que nous avons un système qui vérifie périodiquement qu’ils fonctionnent bien, de façon à détecter rapidement un souci et le résoudre au plus vite.
Jusque là, nous utilisions Shinken pour toute notre supervision : aussi bien celle des sites web que celle des serveurs. Mais nous commencions à nous heurter à différents problèmes :
Shinken est en Python 2, une version totalement obsolète de Python, ce qui n’augure pas bien de la pérennité de l’outil (il est question d’une version en Python 3, mais qui se fait largement attendre)
nous avons trop de sondes (c-à-d de choses à superviser) pour que la vérification des sites se fasse suffisamment régulièrement à mon goût (je veux des tests toutes les 5 minutes, pas tous les quarts d’heure)
Nous devons migrer vers une autre solution de supervision, mais pour ça, il faut du temps que nous n’avons pas. Et Shinken fonctionne toujours, donc ce n’est pas une chose que je juge urgente.
Cependant, avec l’ouverture de Framaspace, le nombre de sites à surveiller allait nécessairement exploser (plus de 1 000 espaces à l’heure actuelle).
Il nous fallait donc une solution de supervision pour les sites pour éviter d’augmenter les problèmes de délai entre chaque vérification de site.
Une devise du monde Unix est « Un outil qui fait une chose et qui le fait bien ». Suivant cela, j’ai cherché des outils de supervision de sites web et de rien d’autre. J’ai trouvé statping-ng et Uptime Kuma.
Malgré leurs qualités, ces solutions souffrent du même problème : l’affichage sur la page d’accueil des résultats de toutes les sondes, avec l’historique des résultats sous forme d’une petite frise chronologique. Avec quelques sites à superviser, pas de souci. Avec plus de 100 sites, soit c’est l’affichage qui ne fonctionne plus, soit c’est le service lui-même qui peine… très fort !
Il nous fallait donc créer nous-même notre outil de supervision !
La solution
Comme la plupart des développeurs, j’ai commencé par le plus important : trouver un nom à notre logiciel ! 😅
Pour rester dans la thématique de la mythologie grecque des développements faits pour Framaspace, j’ai cherché sur le web et suis tombé sur Argos Panoptès, géant aux cent yeux, dont l’épithète Panoptès signifie « celui qui voit tout » (on se contentera de l’appeler « Argos » dans cet article)
La deuxième chose la plus importante dans le développement est… le temps disponible. Et nous n’en disposions pas. C’est pourquoi nous avons pris un prestataire, Alexis Métaireau, développeur entre autres du générateur de site statique Pelican, et de l’outil de gestion de dépenses à plusieurs I Hate money (repris dans l’app cospend sur Nextcloud), pour poser les bases d’Argos, en suivant notre cahier des charges.
Argos devait être simple pour être efficace. L’écran d’accueil est donc dépouillé du superflu et n’indique que le nombre de sites surveillés regroupés par état (inconnu, OK, attention, critique).
Les mêmes informations sont aussi disponibles en JSON via un point d’API. À vous d’en faire ce que vous voulez, comme par exemple afficher une notification sur votre bureau si tout n’est pas au vert, déclencher un son… voire intégrer le résultat d’Argos dans votre solution de supervision pour tout avoir au même endroit ! L’API est auto-documentée sur le logiciel (la documentation est accessible depuis l’interface d’Argos).
La simplicité d’Argos réside aussi dans son mode d’installation : un simple pip install argos-monitoring aussi bien pour le serveur central que pour l’agent, une création d’une base de données PostgreSQL, un fichier de configuration en YAML et c’est tout. Avec ça, on a tout ce qu’il faut pour faire tourner le service.
La robustesse
Un mot : PostgreSQL. J’ai toute confiance en PostgreSQL pour encaisser une forte charge comme pourrait lui envoyer Argos.
Plus concrètement, nous sommes passés de ±300 vérifications avant Framaspace à près de 2 000 en surveillant les espaces créés et Argos ne bronche pas.
Cela fait plusieurs mois maintenant que nous utilisons Argos en conditions réelles et passé la phase de débogage, ça se passe parfaitement bien 🥰
L’évolutivité
Vous ajoutez plein de sites et l’agent qui s’occupe de faire les vérifications et de les envoyer au serveur central ne suffit plus ? On peut ajouter autant d’agents supplémentaires que nécessaire en quelques minutes.
Vous voulez créer une nouvelle manière de vérifier que votre site fonctionne bien ? Le site de documentation est riche d’informations pour les développeur·euses et vous tend les bras 🙂
Les moyens de notifications actuels (mail et Gotify à l’heure de l’écriture de cet article) ne vous conviennent pas ? Le code, en Python, est très propre et il est très simple d’ajouter… à peu près n’importe quel moyen de communication, d’un webhookMattermost à un SMS via une plate-forme quelconque.
Conclusion
Nous avons maintenant une solution de supervision spécialisée simple et efficace, flexible de par la simplicité de son code et qui nous donne déjà entière satisfaction.
Si Argos est déjà pleinement fonctionnel, il ne tient qu’à nous (et à la communauté !) de l’améliorer. Il y a déjà quelques tickets, majoritairement pour améliorer la documentation, mais pas que.
Est-ce qu’Argos Panoptès sera adopté par les administrateurices systèmes, du dimanche ou pas ? On verra bien !
Pour celleux qui se demandent pourquoi une queue de paon en image d’illustration de cet article : la déesse Héra a préservé, sur une queue de paon, les cent yeux d’Argos Panoptès après sa mort.
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 :
à Paris au CICP et en ligne pour une nouvelle session de travail et d’échange avec des chercheur⋅ses de l’IRD.
à 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.
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 :
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.
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
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.
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 ?
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.
L’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).
Un 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é.
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.
Les piles lithium rondes que l’on peut trouver dans les batteries d’ordinateurs portables
Réemploi de vieux ordinateurs (ordinosaures)
La 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!
Autre 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.
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.
Une 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
Vous avez envie de participer au projet ? Vous pouvez nous contacter via notre formulaire de contact, et nous vous tiendrons informé·es de nos prochains petits pas, et rencontres!
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 ?
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!
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.
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 !
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.
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 :
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 !
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 😉
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 !
Lallemand, Carine, Guillaume Gronier, et Alain Robillard-Bastien. Méthodes de design UX: 30 méthodes fondamentales pour concevoir et évaluer les systèmes interactifs. Design Web. Paris: Eyrolles, 2016.
UXmind.eu : Blog francophone sur l’expérience utilisateur·rice rédigé par Carine Lallemand. Transfert des théories et méthodes de design UX de la recherche à la pratique.
