Chronique « Itsik Numérik » d’Emmanuel Revah sur Mozilla

Frédéric Couchet : Nous allons commencer avec la chronique « Itsik Numérik » d’Emmanuel Revah qui va devoir activer son micro s’il veut parler. Bonjour Manu.
Emmanuel Revah : Salut Frédéric. Ça va ?
Frédéric Couchet : Ça va bien. Et toi ?
Emmanuel Revah : Oui, ça va.
Frédéric Couchet : Tu veux nous parler aujourd’hui, je crois, de Mozilla. Je te laisse la parole.
Emmanuel Revah : OK. Cool. Parlons un peu de Mozilla. Pour parler de Mozilla, on va déjà parler de Firefox et un peu d’histoire sur Firefox.

Firefox est un navigateur web qui né à partir de son ancêtre Netscape, repris au début sous le nom merveilleux de Phoenix, Netscape renaît de ces cendres, tel un oiseau de feu ou firebird. C’était beau, léger, rapide et sans merde de taureau ou, pour les francophones, sans bullshit. Peu après, Phoenix a été intégré dans Mozilla, une suite de logiciels tout-en-un, avec un navigateur web, logiciel de courriel, discussion instantanée, éditeur HTML, etc.

Après le gros mastodonte, la suite Mozilla, c’est fini. Maintenant il y a d’un côté Thunderbird, le logiciel de courriel à moitié laissé pour mort, et de l’autre côté Firefox, le truc tellement connu que les gens ne savent même pas que c’est un logiciel libre. Pourtant, Firefox, c’est LE navigateur libre, sécurisé et qui est du côté des utilisateurs… Hum ! Hum ! Pardon, ça me gratte la gorge de dire des conneries pareilles ou alors j’ai un petit coup de COVID-19, je ne sais pas. Déjà, la dernière version de Firefox c’est la version 42 821… Non mais sérieusement, les numéros de version commencent déjà à ressembler à des numéros de séries plus qu’à autre chose. Au moment où j’ai écrit cette chronique, c’était il y a quatre jours, on était déjà à la version 74 !

Oui, Firefox c’est libre, mais Firefox dépend de Mozilla, pas la fondation, Mozilla Corporation, l’entreprise à but lucratif Mozilla. Ils disent avoir créé la corporation pour avoir plus de liberté d’action dans leurs comptes ; sans doute qu’au pays des Donald Trump les entreprises sont plus libres que les associations ou les fondations. Ils disent que Firefox, son code source, etc., appartient à la Fondation. Ainsi la corporation s’occupe des finances, mais ne peut pas prendre le contrôle du logiciel. C’est déjà pas mal, on se souvient tous de MySQL, n’est-ce pas Monty ?

Petit bout d’histoire de MySQL et Monty. Monty qui s’appelle Michael Widenius, je ne sais si je prononce bien, c’est le gars qui a lancé MySQL, c’est une base de données sous licence libre. Monty l’a vendue un jour à Sun Microsystems pour cher, un milliard de dollars, et ensuite il a pleurniché comme un enfant gâté quand Sun à vendu MySQL à Oracle. C’est important de garder les logiciels libres, libres ! Si vous ne voulez pas qu’ils tombent entre les mains des entreprises anti-libre, ne les vendez pas s’il vous plaît !

Bref, ils ont compris maintenant. Moi, je sais bien que le développement coûte « un pognon de dingue », mais le fait que Mozilla soit une entreprise à but lucratif est un piège pour elle-même. Ce janvier, juste ce janvier, ils ont licencié 70 personnes, des ingénieurs et tout, mais de l’autre côté ils investissent plus de 40 millions de dollars pour le développement de nouveaux « produits » ! On dirait un cas de « il n’y a pas d’argent magique » ! Il n’y en a pas pour le personnel, mais pour les nouveaux projets tout beaux, on trouve de la thune fastoche.

C’est quoi ces produits ? Eh bien, il s’agit surtout de services. Oui ! Le centre de l’attention va se tourner vers des services. Ça fait déjà un petit moment d’ailleurs. Mozilla passe tout doucement d’une entreprise de logiciel libre vers une société de services centralisés.
Excitons-nous d’abord sur le cas de Pocket. Il s’agit, à la base, d’une extension liée à un service qui sert à sauvegarder des pages web afin de les consulter plus tard. L’entreprise Pocket a été achetée par Mozilla. La partie extension est devenue libre, mais la partie serveur ne l’est toujours pas. Pocket, un service centralisé et basé sur du logiciel non libre, est directement intégré dans Firefox maintenant, ce n’est plus du tout une extension qu’on installe volontairement, on ne peut pas même pas le désactiver, en tout cas pas facilement. Pour le désactiver il faut aller dans les options avancées qui font peur.
Ensuite il y a Firefox Sync. Firefox Sync c’est le truc qui, comment dire, l’idée de base est géniale. C’est un moyen de synchroniser plein de trucs entre des instances de Firefox, par exemple entre le Firefox de mon ordinateur principal et le Firefox de mon ordinateur de voyage ; ou même avec le Firefox de mon téléphone, si j’avais un ordinateur téléphone. Pour utiliser Firefox Sync, il faut s’inscrire. Déjà la page d’inscription, comme presque toutes les pages d’inscription de tous les trucs qui existent dans le monde, ne dit absolument rien sur ce que c’est. Il faut renseigner son adresse de courriel pour passer à la page suivante et enfin voir les CGU [Conditions générales d’utilisation] et une sorte de description de l’utilité d’un compte Firefox. Petit indice : vous pouvez mettre n’importe quoi pour passer la page et ensuite, enfin, lire les CGU. Franchement, je trouve que ça fait un peu dark patterns ou « interface truquée », vous savez l’interface utilisateur qui a été soigneusement conçue pour tromper ou manipuler les utilisateurs, un peu comme fait Facebook et tous ses potes.

Bref, il y a deux éléments. Il y a le côté navigateur, donc Firefox, et de l’autre côté la partie serveur. Par défaut, Firefox utilise le serveur de Mozilla. C’est cool non ? C’est quoi le problème ? Oui, mais, je veux un Internet décentralisé, je veux utiliser mon propre serveur, en mettre en place un pour mes amis, une association, une entreprise, etc. Eh bien, c’est possible, évidemment, c’est du logiciel libre tout ça. Vous avez eu peur ! Super ! Non ! Attends ! La partie serveur est incroyablement inutilisable, le mode d’emploi prévient qu’il n’y a pas de paquets, ni RPM [Red Hat Package Manager], ni deb [format de fichier des paquets logiciels de la distribution Debian GNU/Linux, NdT], ni rien. C’est-à-dire pas de version facile à installer, un peu comme on fait avec Firefox, on télécharge, on clique et c’est installé et surtout par défaut, c’est surtout ça, l’authentification se fait à travers le serveur d’authentification de Mozilla.

Petit aparté. Firefox Sync est intégré dans Firefox depuis la version 4 et Firefox Accounts, c’est Sync mais un petit peu mieux, la partie authentification, depuis la version 29 de Firefox. Pour info, la version 29 de Firefox c’était il y à deux mois ou 15 ans, je sais pas. Ah si ! C’était en 2007 ! Pardon ! 2007, ça laisse le temps de faire un petit paquet deb non ? C’est tellement vieux que ça aurait pu être déjà inclus dans Debian 5.0, c’est-à-dire en 2009.

Il faut préciser qu’il y a le serveur Sync et le serveur Accounts pour les comptes Firefox, et par défaut, ton serveur Sync personnel dépend du serveur Accounts de Mozilla pour l’authentification. Sympa non ? Toujours pas content ? Bon, si tu insistes espèce de libriste autonomiste, il y a moyen d’installer son propre serveur Accounts. Quand même ! Mais attention, la doc est préfixée d’un avertissement qui dit : « Cette doc est brouillon et incomplète, déso-lol ! P. S : sinon, il y a une image Docker à utiliser à vos risques et périls ». Il y a vraiment marqué ça sur la page d’installation, « à vos risques et périls ». Ça donne grave envie, non ?

Je suis désolé si c’est un peu trop technique pour une chronique radio, mais c’est important. Même si vous arrivez à installer ce bordel bien comme il faut, avec la doc obsolète et éparpillée, il vous reste un dernier obstacle et c’est le plus difficile : indiquer à vos utilisateurs qu’il faut aller dans « about:config » c’est-à-dire les options avancées qui font peur, et changer l’option « identity.sync.tokenserver.uri ». Il faut remplacer « https://token.services.mozilla.com/1.0/sync/1.5 » avec l’URL du serveur que tu viens d’installer.
Si dans un podcast de Libre-Nerd c’est compliqué, imagine auprès de ton asso, ton chaton, ton FAI alternatif et autre, qui veut proposer ce service très sympa et très tentant à des êtres humains. Je me permets de douter de Mozilla qui dit qu’ils font la promotion d’un Internet décentralisé… Non ! Pas avec ce genre de truc en tout cas. Ils font plein de trucs bien, mais là, c’est de la merde de taureau. Pardon, je veux dire du bullshit.

Je vais rajouter une petite couche car c’est vraiment un point qui me fait chier à travers un bouchon de liège : si tu installes ton propre serveur de compte, il faut modifier encore plein d’autres réglages dans le fameux « about:config ». Franchement, du côté utilisateur, on va directement chez Google et on arrête les conneries d’idéaliste libriste égalitariste techno-émancipé.

Firefox Sync n’est pas utilisable sans passer par l’autorité centrale que voudrait devenir Mozilla.
Maintenant, parlons un tout petit peu de Thunderbird en cours. Thunderbird, le logiciel de courriel mourant, sera relancé, grâce à MZLA Technologies Corporation. Sympa ce nom ! Encore une fois, je doute. En effet, la relance de cet oiseau trouvé au bord de la route à moitié mourant car mal nourri depuis bien des années passe par une entreprise à but lucratif qui voudrait financer le développement du logiciel à travers des partenariats et des services. Eh oui, encore des services ! Quand je vois le budget global de Mozilla, environ un demi milliard d’euros par an, et comment ils galèrent à faire tourner deux logiciels, je n’arrive même pas à me dire qu’ils ne font pas n’importe quoi. C’est évident qu’ils doivent arrêter leur dépendance au fric de Google. Et nous, les personnes qui utilisons Firefox et Thunderbird, on doit devenir la source des finances de tout ça ; ça, c’est clair et net. Mais je ne pense pas que la bonne piste est à travers des services qui, pour la plupart, existent déjà ailleurs, notamment par des fournisseurs éthiques, dont les chatons et pas que, il y en a plein. Et encore pire, des services dont les logiciels serveurs ne sont pas utilisables, voire, dans certains cas, même pas libres comme avec Pocket.

Mozilla est en train de mettre les logiciels dont nous avons besoin au second plan, derrière des services tels que des VPN [Virtual Private Network], proxys et bientôt un service de courriel, qui existent déjà ailleurs. Leur objectif ce sont des bénéfices plus qu’un Internet ouvert et participatif. Mozilla ne doit pas être à la fois l’éditeur du logiciel et le seul fournisseur des services qui vont avec, sinon, ce n’est pas vraiment libre.
Bon, j’aime bien Firefox, pour l’instant, j’étais fan depuis l’époque de Phoenix. J’adore le Mozilla, et j’aime me dire qu’il y a un dinosaure qui est de notre côté. Pour les gens qui ont oublié le dinosaure, c’était la mascotte de Mozilla, c’était un dinosaure rouge et noir, dessiné d’ailleurs par Shepard Fairey, l’artiste qui a fait OBEY et l’affiche Hope de Obama. Eh bien notre cher dinosaure a été mis à la retraite en janvier 2017. La mascotte a été enlevée et elle a été remplacée par « :// », le truc des URL. C’est mieux non ? Ça ressemble plus à un logo digne d’une Silicon Valley enfin devenu adulte, un peu comme votre oncle banquier qui a fait mai 68.

J’ai peur, je crains que Mozilla ne soit en train de s’éloigner des valeurs qui nous ont conquis à la base. Le dinosaure me manque !
Frédéric Couchet : Merci Manu pour cette chronique qui fait beaucoup réagir sur le salon web de la radio, je rappelle causecommune.fm, bouton « chat » et salon #libreavous. Je rappelle également que les personnes de l’équipe des chroniques sont libres de leur sujet, aucune censure à l’April, petite relecture. Évidemment si Mozilla veut un droit de réponse, cela pourra faire l’objet d’une belle émission avec toi et Mozilla.

Je précise aux gens qui sont sur le salon web de la radio que Manu, qui vient de faire la chronique, est présent sur le salon donc il va pouvoir répondre à toutes vos remarques, questions, « louanges », je mets des guillemets à « louanges ». Manu, comme tu t’en doutes, ta chronique fait réagir.

En tout cas je te remercie, je te souhaite de passer une bonne fin de journée et on se retrouve le mois prochain.
Emmanuel Revah : Super. Merci beaucoup Fred et merci à tout le monde.
Frédéric Couchet : Merci Manu.

On va passer une pause musicale. On va écouter Nakturnal par Kellee Maize.
Pause musicale : Nakturnal par Kellee Maize.
Voix off : Cause Commune, 93.1.
Frédéric Couchet : Nous venons d’écouter Nakturnal par Kellee Maize, disponible sous licence libre Creative Commons Attribution. Vous retrouverez les références sur le site de l’April, april.org, et sur le site de la radio, causecommune.fm.
Vous écouter toujours l’émission Libre à vous ! sur radio Cause Commune, la voix des possibles, 93.1 en Île-de-France et partout dans le monde sur le site causecommune.fm. Nous allons passer au sujet principal.
[Virgule musicale]

Agilité (un groupe de pratiques basées sur l’auto-organisation d’une équipe, l’ajustement permanent et mutuel… pour viser la satisfaction des équipes et de la structure cliente) et le logiciel libre

Frédéric Couchet : Nous allons poursuivre avec notre sujet principal qui va porter sur le thème agile et logiciel libre, une rencontre sur les valeurs et principes avec notre invité Alexis Monville. Alexis est-ce que tu es bien avec nous ?
Alexis Monville : Oui, Frédéric. Bonjour à tous.
Frédéric Couchet : Bonjour Alexis. Tu es, en version courte, membre de l’équipe de leadership de l’engineering chez Red Hat Je vais te demander une petite présentation personnelle, peut-être préciser un petit peu les mots leadership et engineering. Je te laisse la parole pour une petite présentation personnelle de ton parcours et de ton poste actuel.
Alexis Monville : C’est toujours le risque de me laisser parler en français. Quand je vais parler en français je vais toujours mettre des mots en anglais. En général en France ça passe bien, mais j’ai eu l’expérience au Québec de me faire reprendre plus d’une fois, c’était assez intéressant ; les gens pouvaient me donner des traductions à tous les mots que j’utilisais en anglais, c’était quand même merveilleux. Désolé pour ça, j’ai du mal à traduire certaines choses parce qu’on n’utilise pas souvent les mots traduits.

C’est quoi mon rôle actuel ? Red Hat, j’imagine que dans une émission comme ça…
Frédéric Couchet : Tu peux repréciser rapidement ce qu’est Red Hat.
Alexis Monville : C’est une entreprise qui fait du logiciel pour les entreprises et qui a un modèle de développement open source. Je le dis tout de suite, c’est un modèle de développement open source et on est sur une émission qui parle de logiciel libre.
Frédéric Couchet : On aura l’occasion d’y revenir, oui.
Alexis Monville : S’il y a des gens que ça intéresse, ils pourront comprendre la différence entre ce qu’est un mouvement social et ce qu’est un modèle de développement qui veut se penser en dehors de toute question politique. C’est assez amusant.

Red Hat fabrique des logiciels pour les entreprises et son modèle de développement est l’open source. L’idée c’est, en effet, qu’on va fabriquer des produits à partir de logiciels qui sont libres et que tout ce que l’on fait est sous licence libre. Ce qui fait qu’en fait les deux seules choses qui sont à nous ça doit être le logo et la marque, on a une propriété intellectuelle, ce qui est assez amusant. Ça c’est la particularité de Red Hat. Mon rôle c’est de travailler dans cette équipe qui gère l’ensemble de l’engineering et de travailler à améliorer le fonctionnement des équipes, donc l’équipe de leadership, l’équipe qui gère l’ensemble de l’engineering et l’ensemble des équipes au sein de Red Hat. En version simplifiée c’est ça.
Frédéric Couchet : D’accord. Le sens d’engineering, on va peut-être préciser, on va dire que c’est dans le sens du développement du logiciel et des produits.
Alexis Monville : C’est ça, absolument.
Frédéric Couchet : OK. D’accord. En tout cas, je suis ravi de t’avoir avec nous. On se connaît depuis longtemps, on s’est connus à un moment où tu travaillais pour l’État français, à la Direction générale de modernisation de l’État il y a quelques années. Tu es une des premières personnes à m’avoir parlé d’agilité, c’est pour ça qu’on avait envie d’en parler un petit peu. En plus, je vais te le dire tout de suite, quand on a préparé l’émission, que j’en ai parlé sur certains salons, notamment sur le salon de l’April, il y a quelqu’un qui a réagi un petit peu violemment en disant que l’agilité, peut-être sans donner trop de détails, mais en gros il pouvait mettre en doute l’intérêt de l’agilité, l’utilité. On va essayer d’éclaircir un peu tout ça dans le cadre de cette émission, à la fois sur ce qu’est l’agilité et le lien avec le logiciel libre.

Je te propose déjà, premièrement, d’essayer de nous préciser ce qu’est l’agilité et ce que n’est pas l’agilité, parce que je pense qu’il y a beaucoup de méconnaissance sur ce sujet-là. Déjà en introduction, en premier sujet, l’agilité qu’est-ce que c’est ?
Alexis Monville : Qu’est-ce que c’est ? C’est vrai que c’est un bon sujet parce que quand généralement je commence à expliquer ce que c’est, les gens qui avaient une réaction épidermique par rapport à ça se rendent compte qu’on ne parlait pas de la même chose, du coup c’est quand même assez intéressant de la définir.

Comment c’est venu qu’on parle d’agile ? Il faut remonter un peu en arrière, du coup on va remonter tellement en arrière que probablement certains d’entre vous ne seront même pas nés, mais ça vaut quand même le coup d’en parler. Dans les années 90, ça faisait déjà un certain temps qu’on faisait du logiciel et ça faisait un certain temps qu’on essayait d’améliorer les méthodes de gestion de projet faisant du logiciel. Ces méthodes de gestion de projet étaient inspirées de quoi ? Elles étaient inspirées des autres projets qu’on avait faits avant ? Et qu’est-ce qu’on avait comme autres projets avant ? On avait construit des immeubles, on avait construit des voitures, on avait construit des choses comme ça, et on essayait d’appliquer certains principes de ces méthodes au logiciel.

Ce qui était assez intéressant c’est que, un peu comme aujourd’hui, la plupart des projets logiciels n’arrivaient pas à l’heure, coûtaient beaucoup plus cher que ce qui était prévu et ne satisfaisaient pas leurs utilisateurs. À chaque fois on essayait d’analyser pourquoi et on essayait d’améliorer les méthodes. Les méthodes devenaient de plus en plus grosses, de plus en plus compliquées au point où elles n’étaient pas tellement utilisées. Donc on avait d’énormes corpus méthodologiques, extrêmement lourds à mettre en place, et pourtant ça ne fonctionnait quand même pas. En fait, ce qui se passait, c’est que ça devenait de plus en plus long de développer des logiciels et ce qu’on essayait de faire c’est de planifier, de tout prévoir à l’avance. Comme les utilisateurs savaient que ça allait prendre très longtemps, ils essayaient d’imaginer tous les cas possibles, toutes les choses dont ils pourraient avoir besoin et de le dire dès le début parce qu’ils savaient qu’après ils ne pourraient plus rien ajouter. Donc ça devenait de plus en plus gros, de plus en plus gros.

Dans les années 90, il y a un certain nombre de gens qui ont dit « on prend le problème dans le mauvais sens, il faut qu’on change d’approche et qu’on fasse des méthodes qu’ils ont appelées au départ des méthodes légères de gestion de projet ». C’était une super bonne idée et il y en a plusieurs qui ont eu quelques succès en faisant. Il y a des méthodes qui ont émergé. Extreme Programming est probablement celle qui me plaît le plus et qui m’intéresse le plus. Crystal était aussi une méthode qui était intéressante là-dessus. On a des concepts de ces méthodes qui existent encore et qui sont encore utilisés aujourd’hui, bien sûr.

Ce qui s’est passé pour ces méthodes légères de gestion de projet, c’est que les gens qui étaient à l’origine de ces méthodes se sont rencontrés juste au début des années 2000, en 2001 et se sont dit « c’est quoi les points communs entre toutes nos méthodes ? » À partir de ces points communs ils ont écrit quelque chose qui s’appelle le Manifeste agile. Le Manifeste agile fait souvent référence à quatre valeurs et douze principes.

Il faut voir qu’en fait ces gens ont fait les méthodes, ont utilisé les méthodes et après ils ont regardé les points communs entre ces méthodes pour écrire un Manifeste pour dire « voila ce que l’on fait ».

Je vais vous lire la première phrase du Manifeste agile parce que ça éclaire vraiment, à mon sens, ce qu’est l’agilité. Je vais même le faire en français et je ne suis pas habitué à ça : « Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire ». Juste en regardant ça on voit que ces gens sont pragmatiques. Ils ne nous disent pas qu’ils ont déjà tout trouvé, qu’ils ont déjà tout inventé et que c’est fini, on ne peut plus en discuter. Ils nous disent : « On découvre, on fait par la pratique et on aide les autres à le faire ». Il y a cette idée de « on va apprendre en partageant ». C’est pour ça qu’on va trouver énormément de groupes, de réunions, de meet-ups qui vont se passer dans différents villes, dans différents lieux, pour partager sur ce qui marche, ce qui ne marche pas, ce qu’on a appris en faisant des choses et faire évoluer tout ça.
Frédéric Couchet : D’accord. Avant que tu nous parles notamment du détail des quatre valeurs et aussi des principes, si je comprends bien, en fait on est passé quelque part d’un développement logiciel on va dire, entre guillemets « traditionnel » dans les années 80/90, avec un cahier des charges, un livrable des mois après et une sorte d’effet tunnel où, finalement, ce qui était livré ne correspondait pas à ce que les gens voulaient dès le départ, à une méthode de développement qui est plus itérative, plus incrémentale, plus adaptative avec une réaction par rapport aux attentes de la structure cliente ?
Alexis Monville : Exactement. En fait, c’est ça qu’ils ont appris dans les années 90 et c’est ça qu’ils ont voulu partager au travers du Manifeste en 2001.
Frédéric Couchet : D’accord. Tu nous a lu la première phrase du Manifeste et je précise qu’on mettra évidemment les références sur le site de l’April, april.oprg, et sur causecommune.fm. J’en profite pour rappeler que le salon web, si vous voulez réagir, c’est sur causecommune.fm, bouton « chat » et vous nous rejoignez sur #libreavous. Dans le Manifeste il y a quatre valeurs. C’est quoi ces quatre valeurs qui sont le socle ?
Alexis Monville : Ce socle est assez amusant parce qu’on voit quelle est la situation dans laquelle étaient les développeurs de ces méthodes dans les années 90. On le voit parce qu’ils présentent les valeurs en opposition avec autre chose, ils disent, en fait : « Ces expériences nous ont amenés à valoriser les individus et leurs interactions plus que les processus et les outils. » Ça ne veut pas dire que les processus et les outils n’ont aucune valeur, mais ça veut dire que les individus et leurs interactions ont plus de valeur que ça. Ça c’est important parce qu’on s’est rendu compte que dans les méthodes qu’on dit parfois waterfall, etc.
Frédéric Couchet :

Water quoi ?
Alexis Monville : Waterfall. L’idée c’était ce que tu as décrit en fait : on a une description de ce que l’on voudrait au départ et après ça vient cascade se faire, un joli Gantt chart – j’ai encore utilisé un mot super – comme un joli diagramme Gannt de gestion de projet à l’époque ; ça représente une très jolie cascade.

Les individus et leurs interactions étaient un peu écrasés par les processus et les outils qui étaient mis en place. C’était un peu ça l’idée. Ça c’est la première des valeurs.

Si on regarde ce qui se passe à partir de 2001, je peux décrire toutes les valeurs ou je peux commencer à décrire ce qui s’est passé à partir de 2001 et revenir un peu en arrière après.
Frédéric Couchet : Ce qui te paraît le mieux pour que les gens comprennent, c’est toi l’expert là-dessus.
Alexis Monville : Ce qui se passe à partir de 2001 c’est qu’on commence à entendre parler plus d’agile. Quand on commence à entendre parler plus d’agile, on l’entend par différents canaux et il y a un canal qui va vraiment avoir énormément d’impact, c’est un bouquin qui est écrit par un des signataires du Manifeste qui s’appelle Jeff Sutherland, qui est un des créateurs de la méthode Scrum. En fait, le bouquin s’appelle Faire deux fois plus en deux fois moins de temps [The Art of Doing Twice the Work in Half the Time].
Frédéric Couchet : On précise que Scrum c’est une des méthodes qui permettent de mettre en place l’agilité. C’est ça ?
Alexis Monville : C’est ça. En fait, cette promesse avec le titre de ce bouquin va avoir un impact incroyable. Faire deux fois plus en deux fois moins de temps, ça va avoir un impact incroyable. Ce qui est génial c’est que c’est faux, mais ça va super bien marcher auprès d’un large public de gens qui aimeraient bien pouvoir faire deux fois plus avec deux fois moins d’effort. Ça va vraiment lancer le mouvement de l’agilité mais sur une sorte de malentendu.
Frédéric Couchet : Sur une prémisse fausse quelque part.
Alexis Monville : Oui. Parce qu’en fait si la promesse c’était d’apporter deux fois plus de valeur aux utilisateurs avec deux fois moins d’effort, je pense que tout le monde serait d’accord, parce que je pense qu’on peut aller vers ça. Par contre, faire deux fois plus ce n’est pas le but.
Frédéric Couchet : Si je peux me permettre une intervention c’est peut-être justement ce qui a aussi généré beaucoup de réticence voire de rejet de cette notion, c’est justement le fait de faire deux fois plus par rapport au fait que tu insistes sur le fait de produire plus de valeur pour les individus.
Alexis Monville : Oui, Exactement. Je pense qu’en fait on est partis sur quelque chose qui était une sorte de malentendu et surtout, là maintenant, on est partis avec énormément de gens qui ont envie de passer à l’agilité. Quand il y a énormément de gens qui ont envie de quelque chose, ce qui se passe c’est que c’est une très belle opportunité pour lancer des produits.

On a parlé de services juste avant, dans la chronique d’avant, on peut dire des produits et des services. Du coup on va en lancer, ça va être une grande décennie de lancement de produits et de services qui vont mis en rayon puisqu’on va sortir des tas de choses pour vendre de l’agilité. Et on va t’en vendre en fonction de tes moyens : si tu as un euro, on va te trouver un truc à un euro ; si tu en a dix, on va te trouver des trucs à dix euros, on va te vendre un bouquin ; si tu en as 100, on va peut-être te vendre, je ne sais pas, une petite formation en ligne et si tu en as 1000 on peut même te vendre une certification. Tu pourras être certifié par rapport à une de ces méthodes agiles. C’est quand même merveilleux, deux jours et tu as un badge que tu peux mettre sur ton site. Un truc super !
Frédéric Couchet : Ça c’est la décennie 2000.
Alexis Monville : Ça c’est la décennie 2000 et un peu après, en gros ça va continuer jusqu’à à peu près 2015/2016 où on va continuer à avoir cette énorme demande d’agilité, cette énorme demande d’agile et on va avoir tous ces produits qui vont arriver jusqu’à des niveaux assez incroyables où les gens veulent transformer l’entièreté de leur organisation pour être agiles. Quand tu écoutes ce qu’ils te disent, tu te dis « ah oui, ils veulent être agiles, ils veulent être plus réactifs par rapport au marché, plus souples » et en fait ils sont passés où les individus et leurs interactions dans tout ça ? Elle est passée où l’adaptation au changement quand on fait des plans, des trains et des lancements de trucs qui sont assez énormes ? En fait, on a mis un peu de côté et on a du mal à retrouver les valeurs initiales du Manifeste dans ces grandes méthodes et ces grands frameworks sur lesquels on peut être certifié.
Frédéric Couchet : Framework c’est un cadre de travail on va dire.
Alexis Monville : Oui, excusez-moi.
Frédéric Couchet : C’est aussi un exercice pour moi ! En tout cas c’est intéressant de voir effectivement comment tu replaces les valeurs, les individus au centre de l’agilité alors que finalement, ce qui a été vendu par beaucoup de gens, ce n’est pas du tout ça.
Alexis Monville : Du coup, allons vite regarder les trois autres valeurs.

On a dit « les individus et les interactions plus que les processus et les outils, ça nous donne quelque chose ».

On a dit ensuite « des logiciels opérationnels plus qu’une documentation exhaustive ». Ça fait référence à quoi ? Ça veut dire que si j’écris des spécifications, qu’elles soient générales, détaillées, techniques, ce que l’on veut, et que j’ai 250 pages de spécifications, je vais faire énormément de travail, je vais être très actif à écrire des choses, mais je n’ai pas beaucoup de logiciel. Et quand mes utilisateurs lisent des spécifications, ils interprètent les choses comme ils le veulent. Ce sont les basiques de la communication. Si je leur montre un logiciel opérationnel et qu’ils peuvent jouer avec, ils vont comprendre des choses. Il y a des tas d’exemples qui sont hyper-évidents quand on les voit et quand on voit le logiciel, mais quand on lit les spécifications on ne comprend pas tous la même chose. Je vais vous donner un exemple tout bête, un truc de design de site web : l’équipe de design qui s’occupait de l’univers de la marque avait décidé qu’avant de rentrer dans une catégorie du site web il y aurait une petite animation graphique qui durerait 20 secondes, qui permettrait aux utilisateurs d’entrer dans l’univers de la marque. Si vous avez déjà été sur site web dans votre vie, vous savez que 20 secondes d’animation avant d’aller quelque part après avoir cliqué c’est peut-être exagéré.
Frédéric Couchet : C’est l’horreur !
Alexis Monville : Évidemment, dans les spécifications ça ne se voyait pas. Les designers qui ont travaillé sur une animation de 20 secondes, qui a quand même coûté une fortune pour la première catégorie, quand ils l’ont présentée à la première démo, évidemment les gens qui l’avaient demandé se sont rendu compte immédiatement qu’il y avait un problème. Évidemment, ils savaient très bien qu’ils l’avaient écrit dans les spécifications, qu’ils l’avaient validé. En fait, là l’idée c’était de collaborer pour savoir « c’est quoi la durée qui est acceptable ? » Et là c’est intéressant de travailler et de collaborer directement avec le client plus que de négocier et de dire « attends, c’est écrit dans les spécifications, nous on te les fait toutes comme ça et tu te débrouilles ». C’est ce qui nous permet d’introduire la troisième valeur : c’est la collaboration avec les clients plus que la négociation contractuelle. C’était évident pour l’équipe que, en fait, fabriquer des animations de 20 secondes qu’on n’utiliserait jamais c’était idiot ; collaborer avec le client pour savoir ce qu’est la bonne durée d’une animation qui nous permet de rentrer dans l’univers, est-ce qu’on doit l’afficher à chaque fois ou est-ce qu’on ne l’affiche que la première fois, etc. Il y avait des tas de questions qui pouvaient se poser ; quand on travaille avec le client assis à côté de soi c’est beaucoup plus facile de le faire. Donc collaborer avec le client c’est plus important que de faire tout ce qui est écrit dans les spécifications.

La dernière de ces valeurs c’est l’adaptation au changement plus que le suivi du plan. Je viens de l’évoquer avec cet exemple, c’est plus intéressant de s’adapter au changement que de suivre le plan. Dans l’exemple que je vous donne il y avait un contrat avec d’énormes pénalités de retard, tout était cadré très serré, ça coûtait très cher de faire ce site et pourtant ils ont trouvé le moyen de s’entendre et de s’adapter au changement. Il y avait quand même quelqu’un qui s’occupait de faire les révisions contractuelles toutes les deux semaines, c’était assez terrible pour cette personne, mais c’était intéressant de voir que même dans un cadre très contraint ils ont réussi à aller vers plus de collaboration et plus d’adaptation au changement.

Voilà les quatre valeurs. C’est cette idée, en fait, qu’on a toujours un peu de mal à se comprendre et pour collaborer et faire collaborer des gens qui ont différentes fonctions, qui viennent de différents horizons, eh bien ce n’est pas forcément si facile. Il faut avoir cette intention de le rendre possible et ce n’est pas dans le contrôle qu’on va la fabriquer, c’est dans chercher cette entente et accepter ces feed-backs, ces retours directs du client et s’adapter à tout ça.
Frédéric Couchet : D’accord. Je vais répéter les quatre valeurs si je les ai bien notées :

collaboration avec le client plutôt que négociation et contrat ;

réaction au changement plutôt que le suivi d’un plan ;

le logiciel ou en tout cas un produit plutôt fonctionnel plutôt qu’une documentation complète ;

et la quatrième ce sont les personnes enfin les individus et les interactions plutôt que les processus et les outils.

Ce sont les quatre valeurs.
Alexis Monville : Oui, absolument.
Frédéric Couchet : Je précise à William, en régie, que j’ai un retour bizarre de grésillement dans le casque, ce n’est pas très grave, c’est juste que si ça passe à l’antenne, n’hésitez pas à le signaler sur le salon web.

Dans tout ceci, en fait, il y a une notion qui semble apparaître c’est celle de changement, de transformation : comment on peut initier un changement et une transformation pour se mettre à mettre en place, en action, ces quatre valeurs de l’agilité et les principes qui vont avec ?
Alexis Monville : La question c’est d’où on part et où est-ce qu’on veut aller. Un des points importants c’était de se dire « on s’intéresse aux individus et à leurs interactions, on va collaborer avec une équipe qui a diverses compétences et diverses perspectives et on va collaborer avec le client, avec les utilisateurs eux-mêmes du logiciel ». On part du principe que les utilisateurs du logiciel ne sont pas les développeurs du logiciel. C’est un des points qui est toujours compliqué : quand l’utilisateur du logiciel c’est le même que le développeur du logiciel, on peut prendre des raccourcis qu’on ne peut pas prendre quand on a à faire à un utilisateur pour qui on est relativement proche de la magie quand il utilise quelque chose. Il sait ce qui se passe derrière. Il y a ces choses-là qui viennent dedans.

Comment on met en place les choses ? Je pense qu’on met en place les choses en s’accordant sur l’objectif que l’on veut atteindre. Ça c’est vraiment un truc important. C’est là où le « deux fois plus en deux fois moins de temps » n’est pas suffisant. Il faut s’accorder sur l’objectif que l’on va atteindre et quel l’impact ça va avoir pour les différentes parties prenantes, pour les gens qui sont impliqués là-dedans.

On pourra peut-être y revenir. Ce qui me paraît assez intéressant c’est qu’à partir de 2015/2016 certains des signataires du Manifeste agile vont dire que l’agile est mort. C’est-à-dire après, en gros, 15 ans de produits et de services vendus, de certifications, de formations, de tas de trucs, de grandes transformations, de grands cadres de travail vendus, ils vont dire « c’est mort ! En fait ça n’a pas marché, on a échoué. C’est devenu de nouveau très compliqué, et c’est devenu de nouveau quelque chose qui n’aide pas les gens. »

Il y a une partie des signataires qui vont aller dans ce sens-là. Il y a une autre partie des signataires qui vont dire « ce n’est pas ça le problème. Le problème c’est ce qu’on en a fait, c’est cette productisation qu’on en fait qui n’est pas bonne. Mais si on revient aux valeurs, on peut vraiment permettre aux gens, aux personnes de vraiment collaborer ». En fait, c’est en revenant aux valeurs et aux principes qu’on peut permettre aux gens de collaborer. Et c’est là où je trouve que c’est vraiment intéressant. C’est ça qui m’intéresse après. Ce ne sont pas tellement les différentes pratiques et outils qui existent, c’est de retourner aux valeurs et de se poser des questions. Un exercice que peuvent faire les gens c’est d’aller voir le Manifeste pour le développement agile des logiciels, regarder les douze principes sous-jacents au Manifeste et se poser la question « nous, dans notre équipe, quelles sont les choses que l’on fait déjà, quelles sont les choses avec lesquelles on est d’accord et quelles sont les choses avec lesquelles on n’est pas d’accord ? Ou quelles sont les choses qu’on aurait envie de faire et qu’est-ce qu’on pourrait essayer pour aller dans cette direction-là ? »

Je pense que c’est là qu’on peut initier un vrai changement qui est un vrai changement durable.
Frédéric Couchet : D’accord. En fait ces règles et ces principes, finalement ce sont plus des sources d’inspiration que des règles à suivre formellement. Ça me fait penser à une méthode de développement qui a eu beaucoup de succès il y a quelques années, qui en a sans doute beaucoup, c’est Getting Things Done, GTD, je ne sais plus comment ça se traduit en français, c’est moi qui m’auto-piège, que les choses soient faites avec de très nombreux principes et en fait tellement trop de principes à suivre strictement que ça n’a pas fonctionné. En fait ce sont plutôt des inspirations, des sources d’inspiration et chacun doit avoir sa propre vision et quelque part sa propre interprétation de l’agilité, en gros. C’est bien ça ?
Alexis Monville : oui. Si je prends un autre exemple qui est un exemple classique, il y a des raccourcis que certains vont faire en disant « l’agilité ce sont des gens qui collent des post-it sur les murs. »
Frédéric Couchet : Oui, c’est vrai !
Alexis Monville : Oui, c’est un bon truc, du coup il faut mettre un petit « r » derrière le post-it sinon ce n’est pas bon, mais est-ce que ce sont vraiment des gens qui vont coller des petits papiers autocollants sur des murs ? Pourquoi certains font ça ? Pourquoi ils font ça ? C’est qu’ils trouvent pratique, comme ils sont une équipe colocalisée qui travaille dans la même pièce, d’avoir sur un mur leur plan de travail et de savoir ce qu’ils ont à faire, ce qui est en cours et ce qu’ils ont terminé parce que c’est quand même sympa de célébrer ce qui est terminé. D’avoir ça visuellement pour tous, en permanence, c’est quand même super pratique, donc voilà pourquoi ils font ça. Qu’est-ce qu’ils vont faire aussi ? Eh bien par exemple le matin ils vont tous se réunir en face de ce board et ils vont partager ce qu’ils ont fait hier, ce qu’ils ont appris, ce qu’ils ont comme difficultés, en quoi ils auraient besoin d’aide et qu’est-ce qu’ils ont prévu de faire aujourd’hui. Qu’est-ce que ça va leur permettre ? Ils ont un temps de synchronisation qui leur permet de vérifier qu’ils sont tous toujours alignés dans la même direction et puis d’identifier les besoins de collaboration : « Toi tu as une difficulté avec ce truc-là, moi je connais bien ce domaine, peut-être qu’on peut faire un peu de pair programming pour essayer de trouver ». Ou : « Peut-être que là il y a une technologie qui est complexe, toi tu as travaillé à essayer de l’apprendre et à essayer de comprendre, eh bien peut-être que pour cette fonctionnalité on pourrait faire du world programming, travailler tous ensemble, un clavier et toute l’équipe avec un écran pour mettre en place cette fonctionnalité, comme ça on va apprendre cette nouvelle technologie, cette nouvelle interface de programmation, etc. » Donc on va identifier, grâce à ce temps de synchronisation, des opportunités de collaboration, des opportunités d’apprentissage, des opportunités de s’entraider.
Frédéric Couchet : D’accord.
Alexis Monville : Ça, ça marche, je suis dans une équipe colocalisée. Donc je colle des post-it sur des murs, je me réunis devant un board et ça marche super bien. Ce sont des pratiques qui sont super pour rester synchronisés. Si je suis une équipe distribuée, ça n’a pas de sens et pourtant je pourrais aussi avoir un temps de synchronisation.
Frédéric Couchet : OK. Je propose de parler de la suite après la pause musicale.
[Virgule musicale]
Frédéric Couchet : On va se faire une petite pause. On va écouter El jefe par San Blas Posse. On se retrouve juste après. Belle journée à l’écoute de Cause Commue, la voix des possibles.
Pause musicale : El jefe par San Blas Posse.
Voix off : Cause Commune, 93.1.
Frédéric Couchet : Nous venons d’écouter El jefe par San Blas Posse, disponible sous licence libre Creative Commons Partage à l’identique. Vous retrouverez les références sur le site de l’April, april.org, et sur le site de Cause commune, causecommune.fm. J’espère que vous avez dansé comme nous, en tout cas moi j’ai dansé !

Vous écoutez toujours l’émission Libre à vous ! sur radio Cause Commune, la voix de possibles, 93.1 en Île-de-France et partout dans le monde sur le site causecommune.fm. Je suis Frédéric Couchet le délégué général de l’April.

Nous discutons actuellement avec Alexis Monville de la société Red Hat du thème de l’agilité et du logiciel libre. Je précise que vous pouvez aussi nous rejoindre sur le salon web de la radio, causecommune.fm, bouton « chat » et vous allez sur le salon #libreavous. Il y a des gens qui interagissent. Vous pouvez poser des questions ou faire des réactions.
Je disais que juste avant la pause musicale que nous parlions d’initiation au changement, à la transformation avec la méthode agile et Alexis nous parlait de la question de synchronisation notamment dans les équipes distribuées, c’est-à-dire les équipes qui ne sont pas au même endroit, ce qui va nous permettre de revenir un petit peu sur le logiciel libre, comment certaines, on va dire approches agiles, peuvent bénéficier au logiciel libre.

Je voudrais relancer le sujet sur la synchronisation en équipe distribuée. C’est quoi les bonnes pratiques ou peut-être les méthodes, les conseils que l’agilité propose pour ces équipes distribuées ? Alexis Monville.

Alexis Monville : Merci Frédéric. J’en profite pour dire qu’il y a des gens qui demandent des photos de toi en train de danser sur la musique, sur le salon.
Frédéric Couchet : J’ai vu !
Alexis Monville : OK ! J’avais peur que tu n’aies pas vu. C’est important.

Ce qui est important quand on est une équipe distribuée c’est de partager un petit peu des choses sur ce qui se passe dans son environnement à soi qui est souvent son environnement chez soi. D’ailleurs merci à tous de nous accueillir chez vous puisque, à priori, on est tous chez nous en ce moment, ce qui est un autre sujet qu’on pourra aborder.

Si on regarde les principes et les valeurs du Manifeste agile, il n’y a pas de pratiques qui sont recommandées pour la synchronisation. On dit juste qu’en fait ce serait bien si vous travailliez tous les jours, quotidiennement ensemble.
Frédéric Couchet : D’accord.
Alexis Monville : Comment ? Il y a des équipes qui vont trouver des façons de faire. Et ce qui est amusant c’est qu’en fonction des équipes et des gens, en fonction de qui ils sont, ils vont trouver des façons différentes de faire. J’ai vu des équipes qui sont vraiment distribuées sur énormément de time zones.
Frédéric Couchet : Zones horaires différentes.
Alexis Monville : En fait elles ont très peu de zones de recouvrement dans toute l’équipe, voire pas du tout. Pour certains, la solution qu’ils ont trouvée, c’est d’avoir deux rendez-vous de synchronisation dans la journée avec des gens qui font les deux et qui font le lien entre les différentes personnes des différents fuseaux horaires. OK ! Si ça marche pour eux, c’est chouette !

Il y a d’autres équipes qui se sont dit « en fait nous on ne peut pas avoir de périodes de recouvrement ». Ce qu’ils vont faire c’est qu’ils vont avoir un fichier, souvent un étherpad, et ils vont utiliser cet étherpad comme leur lieu de synchronisation.
Frédéric Couchet : On précise juste qu’un étherpad c’est une sorte de bloc notes en ligne où tout le monde peut modifier le texte sur une page web.
Alexis Monville : Oui, absolument. Donc ils vont utiliser ça, ça va être leur point de rendez-vous et ils vont répondre au même genre de questions que l’on a évoquées tout à l’heure pour les gens qui se réunissaient devant leur tableau avec des étiquettes collantes.

Ces équipes vont trouver des moyens de faire des choses qui sont soit la synchronisation, soit la collaboration. Eh bien oui, quand on fait du pair programming et qu’on est dans le même bureau, on peut s’asseoir derrière le même clavier, le même écran. Quand travaille chacun de chez soi il va falloir trouver d’autres techniques pour le faire, il y a plein de techniques pour faire du pair programming.
Frédéric Couchet : Explique juste en deux mots ce qu’est le pair programming, s’il te plaît.
Alexis Monville : Le pair programming, on a deux développeurs qui vont travailler avec un clavier, un écran.
Frédéric Couchet : D’accord.
Alexis Monville : Généralement, quand on est un manager, on a du mal à accepter que ça va être vraiment super comme idée. Mais quand on a déjà essayé de faire quoi que ce soit à deux plutôt qu’à un, on comprend vite quel va être le bénéfice. La meilleure approche que j’ai pour apprendre à des managers que ce n’est pas mal de faire comme ça, c’est quand ils ont un courrier difficile à écrire ou une note difficile à écrire ou un e-mail difficile à écrire, c’est de se mettre à deux pour l’écrire. On va voir qu’en fait on va écrire quelque chose qui est bien meilleur, plus vite. Pourquoi ? Parce qu’on a cette boucle de feed-back, cette boucle de retour, ces yeux additionnels qui vont nous permettre d’aller beaucoup plus vite.
Frédéric Couchet : D’accord. Je vois que le temps file et c’est quand même une émission qui est consacrée aux libertés numériques, je voudrais qu’on parle un peu du parallèle que tu peux faire avec le logiciel libre, les questions de comment certaines approches agiles peuvent bénéficier au logiciel libre. Déjà est-ce que tu vois un parallèle entre l’agilité et le logiciel libre, vu de ton expérience sur les deux sujets ?
Alexis Monville : Il n’y a déjà rien qui les oppose en fait, ça c’est déjà un truc qui est important. L’importance des utilisateurs est importante dans les deux parties.

Je sais que satisfaire l’utilisateur c’est une notion un peu bizarre, souvent, mais le fait que les utilisateurs et les développeurs travaillent ensemble et qu’on va s’intéresser à satisfaire leurs besoins c’est quelque chose qui est intéressant, quelque chose qu’on retrouve dans le logiciel libre en se disant « je vais avoir un logiciel qu’on va pouvoir adapter à nos besoins ». Ça c’est intéressant.

Un des points que l’on voit sur les premiers logiciels libres qui ont vraiment eu beaucoup de succès c’est que les utilisateurs étaient les développeurs. Ils n’avaient pas ce problème d’avoir cette distance entre l’utilisateur et le développeur. Je crois qu’il y a beaucoup de choses qu’on va trouver dans l’approche agile qui aident à créer ce pont entre les utilisateurs qui ne sont plus les développeurs du produit et qui vont aider les développeurs qui veulent faire du Libre à se rapprocher de leurs utilisateurs. Ça c’est un deuxième pont que je vois.
Frédéric Couchet : Juste préciser sur ce pont-là qu’il y a une distribution logicielle libre bien connue, qui s’appelle Debian GNU/Linux, qui a un contrat social et dans le contrat social, je l’ai sous les yeux, le quatrième point c’est « nos priorités sont nos utilisateurs et utilisatrices et les logiciels libres ». Ça regroupe ce que tu viens de dire.
Alexis Monville : Exactement. C’est pour ça que je ne vois pas d’opposition, je ne vois que des points qui pourraient les rapprocher. Et quand après on s’intéresse aux pratiques, aux différentes méthodes, il y a plein de choses qui sont intéressantes. Quand on se dit « c’est quoi un utilisateur ? » C’est quoi un utilisateur quand on regarde un peu les idées ? Qu’est-ce que l’Impact mapping par exemple, les cartes d’impact introduites par Gojko Adzic. Qu’est-ce que c’est qu’une user story ? Il y a des choses qui sont très intéressantes à regarder dans ce domaine-là.

Quand on regarde les pratiques d’ingénierie qui sont souvent associées aux méthodes agiles comme le TDD. Le TDD c’est un bon exemple. Comment on traduit TDD, Test-Driven Development ?
Frédéric Couchet : Du développement piloté par les tests.
Alexis Monville : Piloté par les tests, voilà. Ça ce sont des pratiques qu’on retrouve dans pas mal de logiciels libres aujourd’hui parce que c’est quand même vraiment beaucoup plus pratique de comprendre, de vraiment comprendre la fonctionnalité en fabricant le test qui va permettre de la développer. Et ça va vraiment permettre de créer le minimum de code pour satisfaire la fonctionnalité.

C’est un truc important la simplicité, parce que la simplicité ça va aider à maintenir et ça va aider à modifier le code par la suite.
Frédéric Couchet : D’accord. Dans le développement logiciel libre, comment certaines approches agiles peuvent bénéficier au logiciel libre en général, donc au développement, aux utilisateurs et utilisatrices ?
Alexis Monville : J’ai pris l’exemple de comment on décrit les utilisateurs avec différents personas. Identifier les différents utilisateurs d’un produit ça permet de ne plus les confondre et de ne pas être confus. Par exemple une confusion classique, c’est celui qui va opérer le logiciel, donc qui va s’occuper de gérer le logiciel quand il tourne et celui qui va utiliser le logiciel à un autre niveau. Ce ne sont pas les mêmes, ils n’ont pas besoin des mêmes choses. Il y en a un qui va s’intéresser à regarder le moteur pendant qu’il tourne et il y en a un qui va utiliser le résultat du moteur. Ce n’est pas la même chose et ils n’ont pas besoin des mêmes choses. C’est comme votre mécanicien quand il regarde votre voiture, il n’a pas besoin de regarder les mêmes choses que vous quand vous la conduisez. C’est intéressant de distinguer les deux utilisateurs, parce que si on n’en a qu’un on va donner à celui qui conduit la voiture des tas d’indications qui ne vont lui servir à rien. Même si on a encore des indications de température d’eau du moteur ou d’huile du moteur sur certaines voitures, il y a assez peu de gens qui les utilisent à part quand ça devient rouge. C’est la même chose dans les logiciels. Donc identifier les personas et comprendre ce qui va vraiment avoir de l’impact pour eux, je pense que ce sont des choses qui sont intéressantes.

Ça ce sont des petites pratiques. Dans les principes ça va être de se dire « je vais présenter un résultat qui fonctionne et je vais demander aux gens de me dire ce qu’ils en pensent ». Ça, ça rejoint pas mal de principes du logiciel libre. On le voit parfois, on le sent parfois un peu oublié dans certains logiciels où les gens essayent d’avoir un gros impact et de sortir un gros truc d’un coup. En fait, on n’est pas très sûr que ça résolve bien le problème que l’on voulait résoudre.
Frédéric Couchet : Tout à l’heure tu as parlé des users story, ce sont les récits d’utilisation, c’est peut-être quelque chose qui peut être important aussi dans le cadre du logiciel libre, parce qu’en fait une histoire d’utilisation c’est comment une personne va décrire ce dont elle a besoin et comment, ensuite, derrière ça va être mis en œuvre, mais la personne décrit le besoin. Quand tu parlais tout à l’heure des utilisateurs et des utilisatrices, l’important c’est que le logiciel soit utilisé par ceux auxquels c’est destiné.
Alexis Monville : Ça a deux bénéfices. Un premier bénéfice c’est qu’on va s’intéresser à l’impact que ça va avoir pour l’utilisateur. Avant de dire ce que l’on veut faire, c’est-à-dire la tâche ou la fonctionnalité qu’on veut avoir, on va s’intéresser à quel est l’impact pour l’utilisateur. Si je prends un exemple de tout à l’heure qui était donné dans la chronique du début, moi, en tant qu’utilisateur, je voudrais pouvoir mettre de côté une page web pour pouvoir la lire plus tard. De quoi j’ai besoin pour faire ça ? Est-ce que j’ai besoin d’un service centralisé quelque part, d’un endroit où je ne sais pas où il est pour pouvoir faire ça ? Peut-être que oui ou peut-être que non, mais la fonctionnalité elle-même n’a aucun rapport avec mon besoin. Il va y avoir des tas de façons de répondre à mon besoin. C’est pour ça, en fait, que c’est intéressant d’abord de regarder vraiment l’impact pour l’utilisateur avant de se poser la question de quelle fonctionnalité je vais faire. Après on peut regarder pour qui, les autres parties prenantes, par exemple pour le constructeur du logiciel ou pour l’entreprise qui va gérer le logiciel, quels sont les bénéfices pour eux d’une certaine fonctionnalité. On va pouvoir comprendre pourquoi certaines entreprises font certains choix. C’est pour ça que je recommande vraiment de regarder l’impact pour l’utilisateur d’abord. Ça c’est une pratique importante.
Frédéric Couchet : D’accord. Toi tu as commencé l’agilité, notamment dans une société qui a peut-être dix ou quinze personnes, je parle de eNovance.
Alexis Monville : Oui.
Frédéric Couchet : Maintenant tu es chez Red Hat où il y a quelques milliers de personnes je pense. Première question : finalement l’agilité c’est à la fois pour les grandes équipes et pour les petites équipes ? Deuxième question, un peu liée, qu’est-ce que ça change de faire de l’agilité entre une petite équipe telle que tu as pu le faire chez eNovance ou dans d’autres structures ou dans une grande équipe telle que Red Hat ?
Alexis Monville : En fait, je pense que le point important c’est qu’on n’est pas très doués pour travailler à plus d’un certain nombre. Je pense que l’être humain n’est pas très vieux en termes d’évolution, ce qui fait qu’on a des fonctions qui évoluent lentement, il y a des choses qui sont câblées depuis longtemps en nous. Quand on veut travailler de manière proche avec des gens, notre groupe de travail est généralement de pas plus de 12 personnes. Et ça, ça rejoint un peu la taille d’une bande que l’on pouvait avoir dans les premiers humains quand ils se baladaient pour faire de la cueillette et de la chasse. Les tribus faisaient à peu près une centaine de personnes. En fait, on retrouve cette taille d’équipe à l’échelle des entreprises. C’est aussi pour ça que quand les entreprises grandissent, souvent on entend les startups dire « au-delà de 15 personnes c’était compliqué, il a fallu complètement réinventer l’organisation ». Quinze personnes ce n’est pas grand ! En fait, on vient de dépasser la taille de la bande initiale. Ils vont redire la même chose quand ils vont dépasser 30, 50, et puis quand ils vont arriver à 100 et quand ils vont arriver à plus de 100 ils vont dire « c’est comme si on était une grande entreprise maintenant, il n’y a pas de différence ». En fait, dès qu’on dépasse la taille de la tribu, ça devient compliqué de se connecter avec les gens qui sont à côté. Pourquoi ? Parce qu’on n’a plus forcément la même notion d’appartenance et de contribution à ce que la tribu, dans son ensemble, essaie de faire.

Quand on parle d’agilité, on peut en parler à différentes tailles. Je crois que ce qui marche vraiment, ce qui est vraiment intéressant, c’est quand on en parle dans l’équipe avec laquelle on collabore toute la journée. C’est là où ça marche vraiment.

Après il faut avoir conscience qu’il y a d’autres équipes autour de nous qui vont essayer d’aller dans un but commun. Il faut se poser la question « c’est quoi ce but commun ? » C’est là qu’il faut avoir des objectifs de plus grand niveau, qui vont sûrement être à l’échelle de la tribu, qui vont permettre à toutes les équipes de se dire « OK ! Si c’est ça nos objectifs au niveau de la tribu, comment nous, notre équipe, on va contribuer à ça ? » C’est ça qu’on essaye de mettre en place. On essaye de présenter des objectifs, d’avoir des grands résultats clefs qui ont un impact sur les utilisateurs, pour permettre à toutes les petites équipes de se dire « OK, moi comment je contribue à ça ? » et de publier ce qu’elles vont faire. Voilà. Nos contributions à ça, ça va être ça. Ça va être ça notre position et on a des connexions à faire avec d’autres équipes parce qu’on a des dépendances entre nous, donc il faut qu’on aille dans le même sens, mais on va s’organiser pour gérer ces dépendances ». Et si on fait ça, eh bien on peut aller à n’importe quelle taille.
Frédéric Couchet : D’accord. Donc même chez Red Hat, on reconstruit quelque part des petites tribus si j’ai bien compris.
Alexis Monville : Oui. On se rend compte que dès qu’on dépasse la taille d’une tribu c’est compliqué, donc il faudrait mieux avoir deux tribus. On n’utilise pas forcément ce vocabulaire-là, je l’utilise là parce que je trouve que c’est plus pratique, c’est plus parlant, mais c’est un peu ce qu’on retrouve.
Frédéric Couchet : D’accord. Comme tu parles de petit nombre, ça me fait penser à une question avec l’actualité. Comment on vit l’agilité ou est-ce que l’agilité peut apporter quelque chose dans cette période de confinement de la population mondiale quasiment ? pas totalement mondiale, mais il y a quand même beaucoup de pays où il y a du confinement maintenant. Dans ce contexte-là, c’est quoi l’agilité ?
Alexis Monville : En fait on va revenir à la première valeur du Manifeste agile. Qu’est-ce qu’elle nous dit ? Elle nous dit que les individus et leurs interactions sont plus importants que les processus et les outils. Ça veut dire que les processus et les outils qu’on a en place aujourd’hui doivent servir les individus et leurs interactions. Moi j’ai été épaté de voir le nombre de gens qui m’ont contacté sur la messagerie instantanée, par messagerie électronique pour me parler, pour me demander juste comment ça allait. Je trouve ça magique, je trouve ça super intéressant. Du coup, on a aussi utilisé la technologie pour faire des trucs : mes enfants sont à Paris pendant que je suis à Bordeaux. On essaye de faire des dîners en ligne avec eux et c’est plutôt marrant. On fait des dîners avec des amis ou des apéros avec des amis, on en a un tout à l’heure, et je trouve ça plutôt marrant de se dire « oui, on est séparés physiquement, mais il ne faut pas qu’on oublie qu’on est des êtres qui avons besoin de cette interaction sociale » – même si je suis un peu introverti, j’ai besoin de cette interaction sociale – et, à un moment donné, il faut s’organiser pour le faire. Je pense que c’est cette idée que la collaboration n’est pas automatique, en fait elle doit être intentionnelle et pour la mettre en place il faut mettre en place une sorte de cadre de collaboration et de temps à autre il faut réfléchir à ce cadre de collaboration pour essayer de voir ce qui fonctionne, voir ce qui pourrait être amélioré et faire évoluer ce cadre de collaboration. Je pense que c’est un des grands points de l’agilité de se dire, à intervalles réguliers, on va réfléchir à ce qui marche, ce qui ne marche pas et on va l’améliorer. La collaboration c’est intentionnel.
Frédéric Couchet : D’accord. Je précise qu’il va nous rester à peu près cinq minutes au maximum. Je précise aux gens qui écoutent que si vous entendez des bruits bizarres derrière c’est mon fils qui fait du hautbois. Je ne sais pas si ça s’entend, même s’il n’est pas à côté de moi.

Avant les questions de conclusion, je crois que tu voulais parler un petit peu de diversité d’agilité. C’est bien ça ?
Alexis Monville : En fait, c’est un point qui me préoccupe beaucoup. On se rend compte depuis plusieurs années qu’on a un problème dans l’informatique en général et dans le logiciel libre en particulier, c’est sur la diversité des gens qui s’intéressent au sujet, qui contribuent. On voit dans les entreprises de la technologie aux États-Unis et dans le monde entier qu’on a un gros problème de diversité. On met souvent en cause la formation en disant « s’il y a 80 % d’hommes dans les formations de computer science, forcément il ne peut pas y avoir moins de 80 % d’hommes dans les entreprises de Tech. Ce qui est un problème c’est que ce n’est pas complètement vrai parce qu’il y a quand même maintenant plusieurs universités où ils sont à 50/50. Pourtant, dans les entreprises de la Tech, il y a des entreprises qui sont à moins que ça. Dans certaines communautés du Libre on est encore à moins, moins que ça. Ce problème de diversité – je parle du genre, mais il y a d’autres aspects de la diversité qui sont importants – c’est un vrai problème pour la collaboration, pour l’innovation et c’est un point sur lequel il faut vraiment être aussi intentionnel, se dire « qu’est-ce que je vais faire pour changer cet état-là ? Qu’est-ce que je vais faire pour changer cette situation ? Et qu’est-ce que je vais faire pour être plus inclusif, pour inclure mieux les gens qui sont différents de moi ? » Parce que si on est différents, on va avoir des points de vue différents, on va penser différemment et si on pense différemment ça va sûrement frotter un peu, mais on devrait en sortir des choses plus intéressantes.
Frédéric Couchet : D’accord. Merci.

Les deux dernières questions : la première, question assez traditionnelle maintenant : pour conclure, quels sont les éléments clefs à retenir de cette émission en moins de deux minutes, Alexis ?
Alexis Monville : La collaboration c’est intentionnel et si vous voulez initier un changement, un exercice que je vous recommande c’est d’aller voir les principes sous-jacents au Manifeste agile et vous poser la question « qu’est-ce qu’ils représentent pour vous ? » Quand vous vous êtes posé cette question, allez voir vos collègues dans votre équipe en disant « qu’est-ce que ça représente pour nous ? Quel est celui sur lequel on a envie de tenter quelque chose, d’expérimenter quelque chose ? » Je ne dis pas que ça va forcément être incroyablement un succès, mais vous aurez au moins expérimenté quelque chose et ça c’est un premier pas vers le changement. Ça ce serait vraiment le truc que je voudrais retenir c’est : on peut expérimenter, on peut essayer des choses et allons-y ! C’est par nous que commence le changement. Ça c’est moins de deux minutes, donc c’est bon, c’est le gros le truc que j’aimerais qu’on puisse faire : c’est pas nous que commence le changement.

C’était quoi ta deuxième question ? Je l’ai oubliée.
Frédéric Couchet : Je ne l’ai pas encore posée. [Rires]. C’est la question bonus : est-ce que tu aurais, je ne sais pas, des conseils de lectures, de séries, de podcasts, pour les personnes qui nous écoutent ? Pas du tout forcément en lien avec le logiciel libre ou avec l’agilité, un coup de cœur à partager.
Alexis Monville : Il y a deux livres que j’ai bien aimés. Il y en a un que j’ai lu récemment que j’ai bien aimé. Il y en a un qui s’appelle The Art of Gathering de Priya Parker. Je sais que proposer un bouquin sur l’art de se réunir à une époque où on ne peut pas se réunir c’est un peu paradoxal, mais c’est un bouquin que j’ai beaucoup aimé, ça m’a rappelé un dîner TEDx, ça m’a amusé, j’ai écrit un article là-dessus et j’ai mis une photo de toi dedans.
Frédéric Couchet : Oui, j’ai vu.
Alexis Monville : C’est un bouquin super intéressant parce que ça nous rappelle les principes de comment on se réunit, pourquoi on se réunit et ça donne envie de le faire en ligne même quand on ne peut pas le faire. Je trouve ça intéressant.

Il y a un deuxième bouquin que j’ai bien aimé qui s’appelle Talking to Strangers de Malcolm Gladwell. J’ai bien aimé ce bouquin parce qu’il y a beaucoup de gens qui vous disent qu’instantanément ils sont capables de se faire une opinion sur les gens et qu’ils savent comment sont les gens, ils savent les lire instantanément. Talking to Strangers explique vraiment bien pourquoi ce n’est pas vrai et ça c’est super important parce que, du coup, ça permet de se dire « je n’aime pas trop cette personne, je devrais faire un petit effort pour essayer de la connaître un peu mieux », parce que c’est probablement là qu’est le problème. Du coup c’est intéressant.
Et puis podcast, si, j’ai un podcast que j’aime beaucoup, qui m’amuse énormément, ça s’appelle Command Line Heroes, c’est Saron Yitbarek qui fait un boulot extraordinaire de narration. Ça parle d’ailleurs un peu des origines du logiciel libre au départ, la quatrième saison est sur le matériel. Le deuxième ou le troisième épisode est très drôle parce qu’il parle du Altair 8800 et ça parle aussi du moment où le logiciel va devenir quelque chose qui est quelque chose qu’on pourrait peut-être vendre. Je trouve ça très intéressant de se replacer au début de l’histoire où le logiciel n’est pas encore soumis au copyright, où ce n’est pas encore arrivé en fait. Je trouve ça très amusant. Je vous recommande cet épisode-là, entre autres, de Command Line Heroes.
Frédéric Couchet : D’accord. On mettra les références sur le site de l’April, april.org et sur le site de Cause Commune, causecommune.fm. Pour les personnes qui veulent prendre et relire les valeurs, les principes agiles dont vient de parler Alexis, la page Wikipédia les liste. Méthode agile, page Wikipédia, vous trouverez la lecture conseillée par Alexis Monville.

Alexis je te remercie grandement de cette participation à cette émission à distance. Je rappelle, Alexis, que tu es membre de l’équipe de leadership de l’engineering chez Red Hat. Je te souhaite une belle fin de journée et à bientôt.
Alexis Monville : Merci beaucoup Frédéric. À bientôt. Merci à tous.
Frédéric Couchet : Merci à toi.

On va faire une pause musicale.
[Virgule musicale]
On va écouter Requiem for a fish. On se retrouve juste après. Belle journée à l’écoute de Cause Commune, la voix des possibles.
Pause musicale : Requiem for a fish par The Freak Fandango Orchestra.
Voix off : Cause Commune, 93.1.
Frédéric Couchet : Nous venons d’écouter Requiem for a fish par The Freak Fandango Orchestra. Aujourd’hui on a choisi des musiques qui bougent parce qu’il faut bouger. C’est disponible sous licence libre Creative Commons Attribution Partage à l’identique. Vous retrouverez les références sur le site de l’April, april.org et sur le site de Cause Commune, causecommune.fm.

Vous écoutez toujours l’émission Libre à vous ! sur radio Cause Commune, la voix de possibles, 93.1 FM en Île-de-France et partout dans le monde sur le site causecommune.fm.
Nous allons passer mainetenant au sujet suivant.
[Virgule musicale]

Chronique « Le libre fait sa comm’ » d’Isabella Vanni sur le projet du jeu du Gnou, avec une interview de mohican, bénévole à l’April

Frédéric Couchet : Parler d’actions de type sensibilisation menées par l’April, annoncer des évènements libristes à venir avec éventuellement des interviews de personnes qui organisent ces évènements, c’est la chronique « Le libre fait sa comm’ » de ma collègue Isabella Vanni, coordinatrice vie associative et responsables projets à l’April.

Isabella va nous parler aujourd’hui avec mohican, bénévole à l’April, du jeu du Gnou. Je leur passe la parole. C’est à toi Isabella.
Isabella Vanni : Merci Fred. Bonjour à toutes et à tous. J’espère que vous m’entendez bien. Je voulais déjà savoir si mohican est avec nous.
mohican : Oui, Bonjour. Vous m’entendez ?
Isabella Vanni : Le son est très faible, mais perso je t’entends. On va essayer de faire notre échange. Merci tout d’abord d’être avec nous aujourd’hui, d’avoir accepté notre invitation. Pour commencer je te propose de te présenter et de nous dire comment et quand tu es devenu bénévole à l’April et plus particulièrement au sein du groupe Sensibilisation ?
mohican : Je suis mohican. En fait ça faisait un moment que je suivais les publications de l’April et quand j’ai vu qu’il y avait une réunion de ce groupe Sensibilisation je suis venu voir puisque moi je fais déjà, à ma petite échelle, de la sensibilisation auprès du grand public, j’ai un blog qui s’appelle « Libère ton ordi » qui est consacré à ça. Quand j’ai vu que l’April commençait à travailler sur un projet de jeu, ça m’a intéressé d’autant plus que j’ai moi-même inventé des jeux à une certaine époque.
Isabella Vanni : Très bien. Donc tu as lié deux grandes passions. Je suis l’animatrice du groupe de travail Sensibilisation de l’April, j’aimerais que ce soit toi à nous en dire plus sur le jeu du Gnou. En quoi ça consiste ? En quoi il s’agit, par exemple, d’un jeu coopératif et d’un jeu pédagogique ?
mohican : L’objectif du jeu c’est évidemment la sensibilisation. On s’est dit que pour sensibiliser aux notions de logiciel libre, c’était important que le jeu ait lui-même une forme, bien sûr il est sous licence libre, mais au-delà de ça, en fait il promeut aussi la coopération puisque c’est une des valeurs du Libre. Donc on en a fait un jeu coopératif où tous les joueurs qui sont autour de la table forment une même équipe et vont pouvoir s’entraider pour atteindre l’objectif du jeu.
Isabella Vanni : En fait il s’agit d’un jeu de plateau, c’est-à-dire qu’on a un pion unique qui représente l’équipe de toutes les personnes qui participent. Le jeu a évolué, on a aussi rajouté pas mal de quiz. En fait c’est un jeu de plateau avec des choses qui peuvent se passer, des questions auxquelles il faut répondre. C’est à travers ce jeu de quiz qu’on en apprend plus sur les enjeux numériques et sur ce qu’on peut faire pour se protéger.
mohican : La partie coopérative du jeu peut se faire de deux façons différentes. Comme tu l’as dit, il y a des quiz auxquels les joueurs doivent répondre. Il y a un joueur qui tient la carte avec la question dessus, mais les autres joueurs peuvent l’aider, ils peuvent donner leur opinion et essayer de l’aider à répondre à la question. C’est la première façon de faire. La deuxième façon de coopérer dans ce jeu : au fur et à mesure qu’on progresse sur le parcours, on tombe sur des cases « danger » et on peut acquérir des protections contre ces dangers. En fait, la coopération peut se faire lorsque par exemple un joueur arrive sur une case « danger » pour laquelle il n’a pas de protection, mais si un autre joueur de l’équipe a une protection il peut tenter de la lui transférer. Donc c’est en ça que ça devient aussi coopératif.
Isabella Vanni : Exactement. C’est le transfert de la protection qui a beaucoup plu aux bénévoles de l’Ubuntu Party en novembre dernier. Ils nous ont vraiment complimentés pour cet aspect du jeu. Est-ce que tu peux nous faire quelques exemples de dangers sur lesquels on peut tomber sur le plateau du jeu ?
mohican : On a conçu le jeu pour qu’il parle des enjeux du numérique d’une façon assez large, donc pas seulement les questions de logiciel libre. Il y a des dangers qui sont liés, bien sûr, au logiciel privateur, des dangers qui sont liés aux abus du copyright, mais il y a aussi des dangers notamment sur le fait d’être traqué sur l’Internet ; il y a des dangers par rapport à la centralisation des services internet. Je ne me souviens plus du cinquième, en tout cas il y a cinq dangers qui couvrent un petit peu quelque chose d’assez large pour les enjeux du numérique. Le dernier enjeu ce sont les actions liberticides, donc l’aspect plutôt juridique.
Isabella Vanni : J’aimerais dire que le jeu, en fait, a évolué. Au départ on n’avait pas les cartes quiz, on posait des questions aux personnes, mais il y avait un grand blanc, surtout si les personnes qui participaient étaient néophytes, voire pas du tout sensibilisées. L’idée d’ajouter des cartes quiz avec des questions QCM ou « oui ou non », « vrai ou faux », en fait est venue suite à un test, une sorte d’atelier qu’on a fait auprès du siège de Belugames, c’est-à-dire un éditeur de jeux coopératifs. On a eu la chance d’être accueillis et de pouvoir faire un test avec des professionnels du jeu coopératif.

mohican, est-ce que tu peux nous dire à quelle étape du projet du jeu du Gnou nous sommes aujourd’hui et, chose très importante, est-ce que les gens qui nous entendent peuvent déjà jouer au jeu du Gnou s’ils le souhaitent ?
mohican : On est dans une version bêta mais qui est assez aboutie. C’est-à-dire que ce qui nous manque maintenant c’est juste de réviser un peu tous les textes, ceux qui sont sur ces questions quiz et les différents descriptifs. Il faut qu’on affine les textes, il faut qu’on affine les graphismes, mais le jeu déjà en tant que tel est tout à fait jouable. On l’a déjà utilisé à plusieurs reprises. On continue à le tester, mais en réel, c’est-à-dire qu’on a déjà imprimé le jeu, c’est un brouillon bien sûr, mais on continue à l’utiliser vraiment.
Isabella Vanni : Les personnes peuvent télécharger les éléments graphiques. On mettra bien évidemment toutes les références, elles sont d’ailleurs déjà sur la page de l’émission d’aujourd’hui. Puisque c’est toi qui as fait beaucoup d’ateliers, de tests sur le jeu, je voulais savoir quels sont les retours de la part du public.
mohican : Ce sont des retours qui sont positifs parce que c’est quand même un sujet qui intéresse les gens. Ils ont toujours l’impression d’apprendre quelque chose en participant au jeu. Ce que je voudrais dire aussi, qui est très important sur ce mode de sensibilisation, par comparaison par exemple avec une conférence, c’est que là on a vraiment les participants qui sont actifs. Ils sont actifs et surtout ils interagissent entre eux. Ce n’est pas juste l’animateur qui va porter la bonne parole ; là on donne vraiment aux participants l’occasion d’échanger entre eux, de raconter leurs expériences, de se poser des questions ensemble, de chercher des réponses ensemble. Donc ils sont actifs et ça c’est important aussi pour les motiver et faire qu’ils s’intéressent vraiment à la chose et qu’ils se sentent entendus.
Isabella Vanni : Je te remercie pour ce retour. J’ai pu constater, en ayant animé des ateliers, que c’est très important aussi pour les animateurs parce qu’on se rend compte en fait de comment on peut améliorer le jeu et c’est important aussi pour les personnes qui pensent en savoir beaucoup. Il y a des personnes qui se sont présentées en disant « je suis libriste, je connais très bien ». Eh bien il y a des personnes qui n’ont pas répondu correctement par exemple à des questions concernant l’idée reçue de la gratuité du logiciel libre. Donc même les personnes qui pensent savoir peuvent apprendre des choses. C’est plutôt plaisant pour un jeu comme le nôtre.

Comme tu disais, on peut déjà jouer, mais il y a encore de la relecture, de la rédaction à faire concernant notamment les cartes quiz, les textes qui accompagnent le jeu. On a aussi trouvé un bénévole qui va réaliser la partie design. Est-ce que tu peux nous dire comment contribuer au jeu ?
mohican : C’est vrai qu’en ce moment c’est un peu difficile de se rencontrer et c’est quand même important de pouvoir faire des réunions pour discuter. On en a fait une, bien sûr en vidéoconférence, il y a quelques jours. C’est vrai que pour les gens qui seraient nouveaux, qui voudraient contribuer sans faire partie du groupe Sensibilisation, ça va être un peu plus compliqué. Par contre, je pense que pour ce qui est de la relecture des textes par exemple, ça peut se faire de façon assez simple. Il faudra télécharger les quiz, tous les intitulés des questions et les réponses et relire. Ce dont on a besoin, par exemple, c’est de deux choses : c’est d’une part que les textes soient vraiment compréhensibles pour un public relativement jeune ; avec ce jeu, d’une part on vise le grand public. Et ce jeu peut se jouer dès l’âge du collège, donc on veut aussi que le vocabulaire utilisé, les tournures de phrase soient compréhensibles pour des jeunes. Ça c’est la première chose à bien regarder.

La deuxième chose c’est que ça soit formulé, que les questions soient formulées de façon non ambiguë pour qu’il n’y ait pas d’hésitation sur ce qu’il faut répondre, oui ou non, à telle ou telle question.
Isabella Vanni : Très bien. C’est important. On a besoin de relecteurs, de personnes qui nous aident à rédiger de nouvelles questions éventuellement. On me dit que notre temps est terminé.
mohican, je te remercie beaucoup d’avoir participé et j’espère qu’on pourra voir notre jeu finalisé bientôt. Merci beaucoup.
mohican : Merci à vous.
Frédéric Couchet : Merci à Isabella et à mohican. C’était le jeu du Gnou. Vous retrouverez les références sur april.org et sur causecommune.fm.

Annonces

Frédéric Couchet : Je vais faire les annonces finales, peut-être pas toutes parce que je regarde le temps. Quelques-unes.

[Virgule musicale]
Frédéric Couchet : Jeudi dernier on a fait une Antenne libre April/Cause Commune sur les services en ligne libres, éthiques, la continuité pédagogique et les CHATONS, le Collectif des Hébergeurs, Alternatifs, Transparents, Ouverts, Neutres et Solidaires. Le podcast est disponible sur le site causecommune.fm et sur le site april.org. Consultez le site des CHATONS avec un « S », chatons au pluriel point org. [chatons.org]

Demain soir il y a une Antenne libre Cause Commune donc mercredi 25 mars à 22 heures sur le thème de vivre mieux le confinement avec des membres des différentes équipes de la radio. Soyez au rendez-vous.

On vous a mis également en ligne une playlist des morceaux de musique libre diffusés dans Libre à vous !, donc huit heures de musique. Un grand merci aux artistes qui ont fait ces titres de musique libre. N’hésitez pas à l’écouter.

On a également toujours besoin d’aide pour le traitement des podcasts pour soulager Sylvain Kuntzmann et Olivier Grieco.

C’était les principales annonces que je fais assez rapidement pour tenir.
À 17 heures, pour les personnes qui nous écoutent sur Internet et en DAB, il y a une émission, je lis : les relations numériques au travail. C’est l’émission Cause à effet à 17 heures en DAB+ et sur Internet.
Notre émission se termine. Je remercie les personnes qui ont participé à l’émission : Emmanuel Revah, Alexis Monville, mohican, Isabella Vanni.

Aux manettes de la régie aujourd’hui William Agasvari.

Merci également à Sylvain Kuntzmann qui va s’occuper du traitement du podcast. Merci à Quentin Gibeaux qui va s’occuper de la découpe du podcast.

Vous retrouverez sur notre site web april.org toutes les références utiles ainsi que sur le site de la radio, causecommune.fm. N’hésitez pas à nous faire des retours pour indiquer ce qui vous a plu mais aussi les points d’amélioration. Toutes vos remarques et questions sont, bien sûr, les bienvenues. Vous pouvez nous contacter notamment par courriel.
Nous vous remercions d’avoir écouté l’émission qui a été, comme je vous l’ai dit au début, enregistrée dans des conditions particulières suite au confinement. Toutes les personnes étaient chez elles. Chez moi j’avais demandé un peu le silence, mais je ne l’ai pas trop obtenu.

Si vous avez aimé l’émission n’hésitez pas à en parler le plus possible autour de vous. Faites également connaître la radio Cause Commune, la voix des possibles.
La prochaine émission aura lieu en direct mardi 31 mars 2020 à 15 heures 30. Notre sujet principal portera sur la politique logiciel libre de la ville de Fleury-les-Aubrais.
Nous vous souhaitons de passer une belle fin de journée. On se retrouve en direct mardi prochain et d’ici là, prenez soin de vous et des autres.
Générique de fin d’émission : Wesh Tone par Realaze.