Merci de nous avoir donné les moyens de continuer !
Le 21 novembre dernier, à l’occasion de l’annonce du projet Framatube, nous avons lancé un appel aux dons : il nous manquait 90 000 € pour boucler notre budget 2018, sachant que notre principale ressource (90 % de notre budget), ce sont vos dons.
Mer-ci !
Aujourd’hui, nous avons atteint cette somme, alors nous voulons prendre le temps de vous dire, tout simplement : merci.
Soutenir et contribuer à nos actions
Chez Framasoft, nous voyons vraiment notre petite association (qui, rappelons-le, est et reste une bande de potes) comme un lieu d’expérimentation concrète des libertés numériques. Y’a des idées qui nous tentent, alors on se lance, et cela nous permet de nous rendre compte si l’idée parle et si sa réalisation est possible, reproductible, dans quelles limites et avec quels moyens.
Vos dons nous soutiennent en cela : nous vous racontons ce que nous faisons, nous annonçons ce que nous allons faire (par exemple avec notre feuille de route pour les trois années à venir : Contributopia). Si vous voulez nous voir avancer dans cette voie, une des manières (et pas la seule !) de nous soutenir et de contribuer, c’est de nous donner de l’argent. Considérer vos dons comme autant de contributions est quelque chose d’assez inhabituel, en fait.
Merci à Aryeom, du projet Ze Marmott pour cette bien belle illustration !
Aujourd’hui, dans la culture des financements participatifs (crowdfundings) où tout don est soumis à une contrepartie, on essaie de transformer la personne qui donne en une espèce de consommatrice, de « client-roi » qui aurait le droit d’afficher des caprices (« je donne si vous faites ceci ou ne faites plus cela », « je donne donc vous devez répondre oui à ma demande », etc.). Cela crée l’illusion de décider sur des détails, mais aucunement le pouvoir de participer à la production commune, ni de s’en emparer après coup.
Ce fonctionnement-là ne nous parle pas. Vos dons sont parmi les indices qui nous indiquent si nous tenons la barre vers le bon cap. Visiblement, affirmer que Dégoogliser c’est bien mais ça ne suffit pas, aller explorer les outils numériques des mondes de Contributopia, c’est un chemin que vous avez envie de parcourir avec nous. Mine de rien, savoir que nos envies résonnent avec les vôtres, voir votre enthousiasme, cela fait chaud au cœur, alors merci de votre confiance.
À quoi va servir votre argent ?
Alors nous avons déjà détaillé cela dans notre dernière newsletter, donc on peut vous dire que, dans les grandes lignes, nous allons continuer. Pour 2018, cela signifie :
Poursuivre les projets historiques de l’association : l’annuaire Framalibre, la maison d’édition Framabook, la liste est longue… et les projets sont libres ;
Avancer sur les actions permettant de reproduire et adapter cette expérience (les CHATONS, Yunohost, etc.) afin que vous puissiez aisément gagner en autonomie ;
Contribuons ensemble vers cette Contributopia. Illustration de David Revoy – Licence : CC-By 4.0
Ça fait court, dit comme ça, mais mine de rien, nous allons avoir une année bien remplie, et des projets qui vont vous demander, régulièrement, d’intervenir et de vous en emparer si vous désirez que cela avance.
De fait, si nous avons atteint les moyens nécessaires pour accomplir ces actions en 2018, il n’est pas trop tard pour donner : nombreux sont les projets que nous avons budgetés de manière raisonnée, et qui seraient accélérés par des fonds supplémentaires. On pense, notamment, à l’avancement de Framatube après mars 2018 : plus nous dépasserons la barre fixée, mieux nous pourrons accompagner ce projet après ce lancement.
Essaimer c’est aimer
Ce n’est pas pour rien que l’on dit « copier, c’est aimer » : les projets libres sont des communs, et ils ne s’épanouissent que si chacun et chacune d’entre nous les cultivons. Par exemple, grâce à vous, nous avons pu accomplir de bien belles choses en 2017 :
La renaissance de l’annuaire Framalibre, qui fut le tout premier projet Framasoft, et qui est riche aujourd’hui de près de 700 notices ;
Encore une fois, un immense merci à toutes les personnes qui nous ont soutenus cette année (et aussi à celles qui ont soutenu d’autres associations comme, par exemple, La Quadrature du Net, Nos Oignons ou l’April).
Et si ce n’est pas encore le cas : n’hésitez pas ! Rappelons que 100€ de dons en 2017 vous permettront de déduire 66€ de vos impôts en 2018… une belle manière de contribuer à nos actions en utilisant vos… contributions 🙂 ! Soutenez Framasoft
Toute l’équipe de Framasoft vous envoie plein de datalove, et vous souhaite de belles fêtes, dans le partage et la chaleur commune.
Qui veut cadenasser le Web ?
Durant longtemps, des canaris et des pinsons ont travaillé dans les mines de charbon. Ces oiseaux étaient utilisés pour donner l’alarme quand les émanations de monoxyde de carbone se faisaient menaçantes.
Dès qu’ils battaient des ailes ou se hérissaient voire mouraient, les mineurs étaient avertis de la présence du gaz avant qu’eux-mêmes ne la perçoivent. Depuis, les alarmes électroniques ont pris le relais, évitant ainsi le sacrifice de milliers d’oiseaux.
Pour Cory Doctorow (faut-il encore présenter cet écrivain et militant des libertés numériques ?), le canari mort dans la mine, c’est le W3C qui a capitulé devant les exigences de l’industrie du divertissement et des médias numériques.
Il fait le bilan des pressions qui se sont exercées, explique pourquoi l’EFF a quitté le W3C et suggère comment continuer à combattre les verrous numériques inefficaces et dangereux.
Avant de commencer la lecture, vous pourriez avoir besoin d’identifier les acronymes qu’il mentionne fréquemment :
EFF : une organisation non-gouvernementale (Electronic Frontier Foundation) et internationale qui milite activement pour les droits numériques, notamment sur le plan juridique et par des campagnes d’information et de mobilisation. En savoir plus sur la page Wikipédia
W3C : un organisme a but non lucratif (World Wide Web Consortium) qui est censé proposer des standards des technologies du Web pour qu’elles soient compatibles. En savoir plus sur la page Wikipédia
DRM : la gestion des droits numériques (Digital Rights Management). Les DRM visent à contrôler l’utilisation des œuvres numériques. En savoir plus sur la page Wikipédia
EME : des modules complémentaires (Encrypted Media Extensions) créés par le W3C qui permettent aux navigateurs d’accéder aux contenus verrouillés par les DRM. En savoir plus sur la page Wikipédia
Alerte aux DRM : comment nous venons de perdre le Web, ce que nous en avons appris , et ce que nous devons faire désormais
Par CORY DOCTOROW
Cory Doctorow (CC-BY-SA Jonathan Worth)
L’EFF s’est battue contre les DRM et ses lois depuis une quinzaine d’années, notamment dans les affaires du « broadcast flag » américain, du traité de radiodiffusion des Nations Unies, du standard européen DVB CPCM, du standard EME du W3C, et dans de nombreuses autres escarmouches, batailles et même guerres au fil des années. Forts de cette longue expérience, voici deux choses que nous voulons vous dire à propos des DRM :
1. Tout le monde sait dans les milieux bien informés que la technologie DRM n’est pas pertinente, mais que c’est la loi sur les DRM qui est décisive ;
2. La raison pour laquelle les entreprises veulent des DRM n’a rien à voir avec le droit d’auteur.
Ces deux points viennent d’être démontrés dans un combat désordonné et interminable autour de la standardisation des DRM dans les navigateurs, et comme nous avons consacré beaucoup d’argent et d’énergie à ce combat, nous aimerions retirer des enseignements de ces deux points, et fournir une feuille de route pour les combats à venir contre les DRM.
Les DRM : un échec technologique, une arme létale au plan légal
Voici, à peu près, comment fonctionnent les DRM : une entreprise veut fournir à un client (vous) un contenu dématérialisé (un film, un livre, une musique, un jeu vidéo, une application…) mais elle veut contrôler ce que vous faites avec ce contenu une fois que vous l’avez obtenu.
Alors elles chiffrent le fichier. On adore le chiffrement. Parce que ça fonctionne. Avec relativement peu d’efforts, n’importe qui peut chiffrer un fichier de sorte que personne ne pourra jamais le déchiffrer à moins d’obtenir la clef.
Supposons qu’il s’agisse de Netflix. Ils vous envoient un film qui a été chiffré et ils veulent être sûrs que vous ne pouvez pas l’enregistrer ni le regarder plus tard depuis votre disque dur. Mais ils ont aussi besoin de vous donner un moyen de voir le film. Cela signifie qu’il faut à un moment déchiffrer le film. Et il y a un seul moyen de déchiffrer un fichier qui a été entièrement chiffré : vous avez besoin de la clef.
Donc Netflix vous donne aussi la clef de déchiffrement.
Mais si vous avez la clef, vous pouvez déchiffrer les films de Netflix et les enregistrer sur votre disque dur. Comment Netflix peut-il vous donner la clef tout en contrôlant la façon dont vous l’utilisez ?
Netflix doit cacher la clef, quelque part dans votre ordinateur, dans une extension de navigateur ou une application par exemple. C’est là que la technologie atteint ses limites. Bien cacher quelque chose est difficile. Mais bien cacher quelque chose dans un appareil que vous donnez à votre adversaire pour qu’il puisse l’emporter avec lui et en faire ce qu’il veut, c’est impossible.
Peut-être ne pouvez-vous pas trouver les clefs que Netflix a cachées dans votre navigateur. Mais certains le peuvent : un étudiant en fin d’études qui s’ennuie pendant un week-end, un génie autodidacte qui démonte une puce dans son sous-sol, un concurrent avec un laboratoire entier à sa disposition. Une seule minuscule faille dans la fragile enveloppe qui entoure ces clefs et elles sont libérées !
Et une fois que cette faille est découverte, n’importe qui peut écrire une application ou une extension de navigateur avec un bouton « sauvegarder ». C’est l’échec et mat pour la technologie DRM (les clés fuitent assez souvent, au bout d’un temps comparable à celui qu’il faut aux entreprises de gestion des droits numériques pour révoquer la clé).
Il faut des années à des ingénieurs talentueux, au prix de millions de dollars, pour concevoir des DRM. Qui sont brisés au bout de quelques jours, par des adolescents, avec du matériel amateur. Ce n’est pas que les fabricants de DRM soient stupides, c’est parce qu’ils font quelque chose de stupide.
C’est là qu’intervient la loi sur les DRM, qui donne un contrôle légal plus puissant et plus étendu aux détenteurs de droits que les lois qui encadrent n’importe quel autre type de technologie. En 1998, le Congrès a adopté le Digital Milennium Copyright Act, DCMA dont la section 1201 prévoit une responsabilité pénale pour quiconque contourne un système de DRM dans un but lucratif : 5 ans d’emprisonnement et une amende de 500 000 $ pour une première infraction. Même le contournement à des fins non lucratives des DRM peut engager la responsabilité pénale. Elle rend tout aussi dangereux d’un point de vue légal le simple fait de parler des moyens de contourner un système de DRM.
Ainsi, la loi renforce les systèmes de DRM avec une large gamme de menaces. Si les gens de Netflix conçoivent un lecteur vidéo qui n’enregistrera pas la vidéo à moins que vous ne cassiez des DRM, ils ont maintenant le droit de porter plainte – ou faire appel à la police – contre n’importe quel rival qui met en place un meilleur service de lecture vidéo alternatif, ou un enregistreur de vidéo qui fonctionne avec Netflix. De tels outils ne violent pas la loi sur le droit d’auteur, pas plus qu’un magnétoscope ou un Tivo, mais puisque cet enregistreur aurait besoin de casser le DRM de Netflix, la loi sur les DRM peut être utilisée pour le réduire au silence.
La loi sur les DRM va au-delà de l’interdiction du contournement de DRM. Les entreprises utilisent aussi la section 1201 de la DMCA pour menacer des chercheurs en sécurité qui découvrent des failles dans leurs produits. La loi devient une arme qu’ils peuvent pointer sur quiconque voudrait prévenir leurs consommateurs (c’est toujours vous) que les produits auxquels vous faites confiance sont impropres à l’usage. Y compris pour prévenir les gens de failles dans les DRM qui pourraient les exposer au piratage.
Et il ne s’agit pas seulement des États-Unis, ni du seul DCMA. Le représentant du commerce international des États-Unis a « convaincu » des pays dans le monde entier d’adopter une version de cette règle.
Les DRM n’ont rien à voir avec le droit d’auteur
La loi sur les DRM est susceptible de provoquer des dommages incalculables. Dans la mesure où elle fournit aux entreprises le pouvoir de contrôler leurs produits après les avoir vendus, le pouvoir de décider qui peut entrer en compétition avec elles et sous quelles conditions, et même qui peut prévenir les gens concernant des produits défectueux, la loi sur les DRM constitue une forte tentation.
Certaines choses ne relèvent pas de la violation de droits d’auteur : acheter un DVD pendant que vous êtes en vacances et le passer quand vous arrivez chez vous. Ce n’est de toute évidence pas une violation de droits d’auteur d’aller dans un magasin, disons à New Delhi, d’acheter un DVD et de le rapporter chez soi à Topeka. L’ayant droit a fait son film, l’a vendu au détaillant, et vous avez payé au détaillant le prix demandé. C’est le contraire d’une violation de droits d’auteur. C’est l’achat d’une œuvre selon les conditions fixées par l’ayant droit. Mais puisque le DRM vous empêche de lire des disques hors-zone sur votre lecteur, les studios peuvent invoquer le droit d’auteur pour décider où vous pouvez consommer les œuvres sous droit d’auteur que vous avez achetées en toute honnêteté.
D’autres non-violations : réparer votre voiture (General Motors utilise les DRM pour maîtriser qui peut faire un diagnostic moteur, et obliger les mécaniciens à dépenser des dizaines de milliers de dollars pour un diagnostic qu’ils pourraient sinon obtenir par eux-mêmes ou par l’intermédiaire de tierces parties); recharger une cartouche d’encre (HP a publié une fausse mise à jour de sécurité qui a ajouté du DRM à des millions d’imprimantes à jet d’encre afin qu’elles refusent des cartouches reconditionnées ou venant d’un tiers), ou faire griller du pain fait maison (même si ça ne s’est pas encore produit, rien ne pourrait empêcher une entreprise de mettre des DRM dans ses grille-pains afin de contrôler la provenance du pain que vous utilisez).
Ce n’est pas non plus une violation du droit d’auteur de regarder Netflix dans un navigateur non-approuvé par Netflix. Ce n’est pas une violation du droit d’auteur d’enregistrer une vidéo Netflix pour la regarder plus tard. Ce n’est pas une violation du droit d’auteur de donner une vidéo Netflix à un algorithme qui pourra vous prévenir des effets stroboscopiques à venir qui peuvent provoquer des convulsions potentiellement mortelles chez les personnes atteintes d’épilepsie photosensible.
Ce qui nous amène au W3C
Le W3C est le principal organisme de normalisation du Web, un consortium dont les membres (entreprises, universités, agences gouvernementales, associations de la société civile entre autres) s’impliquent dans des batailles sans fin concernant le meilleur moyen pour tout le monde de fournir du contenu en ligne. Ils créent des « recommandations » (la façon pour le W3C de dire « standards »), ce sont un peu comme des étais invisibles qui soutiennent le Web. Ces recommandations, fruits de négociations patientes et de compromis, aboutissent à un consensus des principaux acteurs sur les meilleures (ou les moins pires) façons de résoudre certains problèmes technologiques épineux.
En 2013, Netflix et quelques autres entreprises du secteur des médias ont convaincu le W3C de commencer à travailler sur un système de DRM pour le Web. Ce système de DRM, Encrypted Media Extensions, constitue un virage à 180 degrés par rapport aux habitudes du W3C. Tout d’abord, les EME ne seraient pas un standard à part entière : l’organisation spécifierait une API au travers de laquelle les éditeurs et les vendeurs de navigateurs pourraient faire fonctionner les DRM, mais le « module de déchiffrement du contenu » (content decryption module, CDM) ne serait pas défini par la norme. Ce qui signifie que les EME n’ont de norme que le nom : si vous lanciez une entreprise de navigateurs en suivant toutes les recommandations du W3C, vous seriez toujours incapables de jouer une vidéo Netflix. Pour cela, vous auriez besoin de la permission de Netflix.
Je n’exagère pas en disant que c’est vraiment bizarre. Les standards du Web existent pour assurer « une interopérabilité sans permission ». Les standards de formatage de texte sont tels que n’importe qui peut créer un outil qui peut afficher les pages du site web du New York Times, les images de Getty ou les diagrammes interactifs sur Bloomberg. Les entreprises peuvent toujours décider de qui peut voir quelles pages de leur site web (en décidant qui possède un mot de passe et quelles parties du site sont accessibles par chaque mot de passe), mais elles ne décident pas de qui peut créer le programme de navigateur web dans lequel vous entrez le mot de passe pour accéder au site.
Un Web où chaque éditeur peut choisir avec quels navigateurs vous pouvez visiter son site est vraiment différent du Web historique. Historiquement, chacun pouvait concevoir un nouveau navigateur en s’assurant qu’il respecte les recommandations du W3C, puis rivaliser avec les navigateurs déjà présents. Et bien que le Web ait toujours été dominé par quelques navigateurs, le navigateur dominant a changé toutes les décennies, de sorte que de nouvelles entreprises ou même des organisations à but non lucratif comme Mozilla (qui a développé Firefox) ont pu renverser l’ordre établi. Les technologies qui se trouvaient en travers de cette interopérabilité sans permission préalable – comme les technologies vidéos brevetées – ont été perçues comme des entraves à l’idée d’un Web ouvert et non comme des opportunités de standardisation.
Quand les gens du W3C ont commencé à créer des technologies qui marchent uniquement quand elles ont reçu la bénédiction d’une poignée d’entreprises de divertissement, ils ont mis leurs doigts – et même leurs mains – dans l’engrenage qui assurera aux géants de la navigation un règne perpétuel.
Mais ce n’est pas le pire. Jusqu’aux EME, les standards du W3C étaient conçus pour donner aux utilisateurs du Web (i.e. vous) plus de contrôle sur ce que votre ordinateur fait quand vous visitez les sites web d’autres personnes. Avec les EME, et pour la toute première fois, le W3C est en train de concevoir une technologie qui va vous enlever ce contrôle. Les EME sont conçus pour autoriser Netflix et d’autres grosses entreprises à décider de ce que fait votre navigateur, même (et surtout) quand vous êtes en désaccord avec ce qui devrait se passer.
Il y a un débat persistant depuis les débuts de l’informatique pour savoir si les ordinateurs existent pour contrôler leurs utilisateurs, ou vice versa (comme le disait l’informaticien visionnaire et spécialiste de l’éducation Seymour Papert « les enfants devraient programmer les ordinateurs plutôt que d’être programmés par eux » – et ça s’applique aussi bien aux adultes). Tous les standards du W3C jusqu’en 2017 ont été en faveur du contrôle des ordinateurs par les utilisateurs. Les EME rompent avec cette tradition. C’est un changement subtil mais crucial.
…et pourquoi le W3C devrait faire ça ?
Aïe aïe aïe. C’est la question à trois milliards d’utilisateurs.
La version de cette histoire racontée par le W3C ressemble un peu à ce qui suit. L’apparition massive des applications a affaibli le Web. À l’époque « pré-applis», le Web était le seul joueur dans la partie, donc les sociétés devaient jouer en suivant ses règles : standards libres, Web libre. Mais maintenant que les applications existent et que presque tout le monde les utilise, les grandes sociétés peuvent boycotter le Web, obligeant leurs utilisateurs à s’orienter vers les applications. Ce qui ne fait qu’accélérer la multiplication des applis, et affaiblit d’autant plus le Web. Les applications ont l’habitude d’implémenter les DRM, alors les sociétés utilisant ces DRM se sont tournées vers les applis. Afin d’empêcher les entreprises du divertissement de tuer le Web, celui-ci doit avoir des DRM également.
Toujours selon cette même théorie, même si ces sociétés n’abandonnent pas entièrement le Web, il est toujours préférable de les forcer à faire leurs DRM en suivant le W3C que de les laisser faire avec les moyens ad hoc. Laissées à elles-mêmes, elles pourraient créer des DRM ne prenant pas en compte les besoins des personnes à handicap, et sans l’influence modératrice du W3C, ces sociétés créeraient des DRM ne respectant pas la vie privée numérique des utilisateurs.
On ne peut pas espérer d’une organisation qu’elle dépense des fortunes pour créer des films ou en acquérir des licences puis distribue ces films de telle sorte que n’importe qui puisse les copier et les partager.
Nous pensons que ces arguments sont sans réel fondement. Il est vrai que le Web a perdu une partie de sa force liée à son exclusivité du début, mais la vérité c’est que les entreprises gagnent de l’argent en allant là où se trouvent leurs clients. Or tous les clients potentiels ont un navigateur, tandis que seul les clients déjà existants ont les applications des entreprises. Plus il y aura d’obstacles à franchir entre vous et vos clients, moins vous aurez de clients. Netflix est sur un marché hyper-compétitif avec des tonnes de nouveaux concurrents (p.ex. Disney), et être considéré comme « ce service de streaming inaccessible via le Web » est un sérieux désavantage.
Nous pensons aussi que les médias et les entreprises IT auraient du mal à se mettre d’accord sur un standard pour les DRM hors W3C, même un très mauvais standard. Nous avons passé beaucoup de temps dans les salles remplies de fumée où se déroulait la standardisation des systèmes de DRM ; la dynamique principale était celles des médias demandant le verrouillage complet de chaque image de chaque vidéo, et des entreprises IT répondant que le mieux que quiconque puisse espérer était un ralentissement peu efficace qu’elles espéraient suffisant pour les médias. La plupart du temps, ces négociations s’effondrent sans arriver nulle part.
Il y a aussi la question des brevets : les entreprises qui pensent que les DRM sont une bonne idée adorent les brevets logiciels, et le résultat est un fouillis sans nom de brevets qui empêchent de parvenir à faire quoi que ce soit. Le mécanisme de regroupement de brevets du W3C (qui se démarque par sa complétude dans le monde des standards et constitue un exemple de la meilleure façon d’accomplir ce genre de choses) a joué un rôle indispensable dans le processus de standardisation des DRM. De plus, dans le monde des DRM, il existe des acteurs-clefs – comme Adobe – qui détiennent d’importants portfolios de brevets mais jouent un rôle de plus en plus réduit dans le monde des DRM (l’objectif avoué du système EME est de « tuer Flash »).
Si les entreprises impliquées devaient s’asseoir à la table des négociations pour trouver un nouvel accord sur les brevets sans le framework du W3C, n’importe laquelle de ces entreprises pourrait virer troll et décider que les autres doivent dépenser beaucoup d’argent pour obtenir une licence sur leurs brevets – elle n’aurait rien à perdre à menacer le processus de négociations et tout à gagner même sur des droits par utilisateur, même minuscules, pour quelque chose qui sera installé dans trois milliards de navigateurs.
En somme, il n’y a pas de raison de penser que les EME ont pour objectif de protéger des intérêts commerciaux légitimes. Les services de streaming vidéo comme Netflix reposent sur l’inscription de leurs clients à toute une collection, constamment enrichie avec de nouveaux contenus et un système de recommandations pour aider ses utilisateurs à s’y retrouver.
Les DRM pour les vidéos en streaming sont ni plus ni moins un moyen d’éviter la concurrence, pas de protéger le droit d’auteur. L’objectif des DRM est de munir les entreprises d’un outil légal pour empêcher des activités qui seraient autorisées sinon. Les DRM n’ont pas vocation à « fonctionner » (au sens de prévenir les atteintes au droit d’auteur) tant qu’ils permettent d’invoquer le DMCA.
Pour vous en convaincre, prenez simplement l’exemple de Widevine, la version des EME de Google. Ce mastodonte a racheté la boîte qui développait Widevine en 2010, mais il a fallu attendre 2016, pour qu’un chercheur indépendant se penche réellement sur la façon dont elle empêchait la fuite de ses vidéos. Ce chercheur, David Livshits a remarqué que Widevine était particulièrement facile à contourner, et ce dès sa création, et que les erreurs qui rendaient Widevine aussi inefficace étaient évidentes, même avec un examen superficiel. Si les millions de dollars et le personnel hautement qualifié affectés aux EME avaient pour but de créer une technologie qui lutterait efficacement contre les atteintes au droit d’auteur, alors vous pourriez croire que Netflix ou une des autres entreprises de médias numériques impliquées dans les négociations auraient utilisé une partie de toutes ces ressources à un rapide audit, pour s’assurer que leur produit fonctionne réellement comme annoncé.
(Détail amusant : Livshits est un Israélien qui travaille à l’université Ben Gourion, et il se trouve que l’Israël est un des rares pays qui ne condamnent pas les violations de DRM, ce qui signifie que les Israéliens font partie des seules personnes qui peuvent faire ce type de recherche, sans craintes de représailles juridiques)
Mais la plus belle preuve que les EME étaient tout simplement un moyen d’éliminer les concurrents légitimes, et non une tentative de protection du droit d’auteur, la voici.
Une expérience sous contrôle
Lorsque l’EFF a rejoint le W3C, notre principale condition était « ne faites pas de DRM ».
Nous avons porté l’affaire devant l’organisation, en décrivant la façon dont les DRM interférent avec les exceptions aux droits auteurs essentielles (comme celles qui permettent à chaque individu d’enregistrer et modifier un travail protégé par droits d’auteur, dans le cadre d’une critique, ou d’une adaptation) ainsi que la myriade de problèmes posés par le DMCA et par d’autres lois semblables à travers le monde.
L’équipe de direction de la W3C a tout simplement réfuté tous les arguments à propos des usages raisonnables et des droits d’utilisateurs prévus par le droit d’auteur, comme étant, en quelque sorte, des conséquences malheureuses de la nécessité d’éviter que Netflix n’abandonne le Web, au profit des applications. Quant au DMCA, ils ont répondu qu’ils ne pouvaient faire quoi que ce soit à propos de cette loi irrationnelle, mais qu’ils avaient la certitude que les membres du W3C n’avaient aucunement l’intention de violer le DMCA, ils voulaient seulement éviter que leurs films de grande valeur ne soient partagés sur Internet.
Nous avons donc changé de stratégie, et proposé une sorte d’expérience témoin afin de savoir ce que les fans de DRM du W3C avaient comme projets.
Le W3C est un organisme basé sur le consensus : il crée des standards, en réunissant des gens dans une salle pour faire des compromis, et aboutir à une solution acceptable pour chacun. Comme notre position de principe était « pas de DRM au W3C » et que les DRM sont une si mauvaise idée, il était difficile d’imaginer qu’un quelconque compromis pouvait en sortir.
Mais après avoir entendu les partisans du DRM nier leurs abus du DCMA, nous avons pensé que nous pouvions trouver quelque chose qui permettrait d’avancer par rapport à l’actuel statu quo et pourrait satisfaire le point de vue qu’ils avaient évoqué.
Nous avons proposé un genre de pacte de non-agression par DRM, par lequel les membres du W3C promettraient qu’ils ne poursuivraient jamais quelqu’un en justice en s’appuyant sur des lois telles que la DMCA 1201, sauf si d’autres lois venaient à être enfreintes. Ainsi, si quelqu’un porte atteinte à vos droits d’auteur, ou incite quelqu’un à le faire, ou empiète sur vos contrats avec vos utilisateurs, ou s’approprie vos secrets de fabrication, ou copie votre marque, ou fait quoique ce soit d’autre, portant atteinte à vos droits légaux, vous pouvez les attaquer en justice.
Mais si quelqu’un s’aventure dans vos DRM sans enfreindre aucune autre loi, le pacte de non-agression stipule que vous ne pouvez pas utiliser le standard DRM du W3C comme un moyen de les en empêcher. Cela protégerait les chercheurs en sécurité, cela protégerait les personnes qui analysent les vidéos pour ajouter des sous-titres et d’autres outils d’aide, cela protégerait les archivistes, qui ont légalement le droit de faire des copies, et cela protégerait ceux qui créent de nouveaux navigateurs.
Si tout ce qui vous intéresse c’est de créer une technologie efficace contre les infractions à la loi, ce pacte ne devrait poser aucun problème. Tout d’abord, si vous pensez que les DRM sont une technologie efficace, le fait qu’il soit illégal de les critiquer ne devrait pas avoir d’importance.
Et étant donné que le pacte de non-agression permet de conserver tous les autres droits juridiques, il n’y avait aucun risque que son adoption permette à quelqu’un d’enfreindre la loi en toute impunité. Toute personne qui porterait atteinte à des droits d’auteur (ou à tout autre droit) serait dans la ligne de mire du DMCA, et les entreprises auraient le doigt sur la détente.
Pas surprenant, mais très décevant
Bien entendu, ils ont détesté cette idée.
Les studios, les marchands de DRM et les grosses entreprises membres du W3C ont participé à une « négociation » brève et décousue avant de voter la fin des discussions et de continuer. Le représentant du W3C les a aidés à éviter les discussions, continuant le travail sur la charte de EME sans prévoir de travail en parallèle sur la protection du Web ouvert, même quand l’opposition à l’intérieur du W3C grandissait.
Le temps que la poussière retombe, les EME ont été publiés après le vote le plus controversé que le W3C ait jamais vu, avec le représentant du W3C qui a déclaré unilatéralement que les problèmes concernant la sûreté des recherches, l’accessibilité, l’archivage et l’innovation ont été traités au mieux (malgré le fait que littéralement rien de contraignant n’a été décidé à propos de ces sujets). La recherche de consensus du W3C a été tellement détournée de son cours habituel que la publication de EME a été approuvée par seulement 58% des membres qui ont participé au vote final, et nombre de ces membres ont regretté d’avoir été acculés à voter pour ce à quoi ils avaient émis des objections.
Quand le représentant du W3C a déclaré que n’importe quelle protection pour un Web ouvert était incompatible avec les souhaits des partisans des DRM, cela ressemblait à une justification ironique. Après tout, c’est comme ça que l’on a commencé avec l’EFF insistant sur le fait que les DRM n’étaient pas compatibles avec les révélations de faille de sécurité, avec l’accessibilité, avec l’archivage ou encore l’innovation. Maintenant, il semble que nous soyons tous d’accord.
De plus, ils se sont tous implicitement mis d’accord pour considérer que les DRM ne concernent pas la protection du droit d’auteur. Mais concerne l’utilisation du droit d’auteur pour s’emparer d’autres droits, comme celui de décider qui peut critiquer ou non votre produit – ou qui peut le concurrencer.
Le simulacre de cryptographie des DRM implique que ça marche seulement si vous n’êtes pas autorisé à comprendre ses défauts. Cette hypothèse s’est confirmée lorsqu’un membre du W3C a déclaré au consortium qu’il devrait protéger les publications concernant les « environnements de tests de confidentialité » des EME permettant l’espionnage intrusif des utilisateurs, et dans la minute, un représentant de Netflix a dit que cette option n’était même pas envisageable.
D’une certaine façon, Netflix avait raison. Les DRM sont tellement fragiles, tellement incohérents, qu’ils sont simplement incompatibles avec les normes du marché et du monde scientifique, où tout le monde est libre de décrire ses véritables découvertes, même si elles frustrent les aspirations commerciales d’une multinationale.
Le W3C l’a implicitement admis, car il a tenté de réunir un groupe de discussion pour élaborer une ligne de conduite à destination des entreprises utilisant l’EME : dans quelle mesure utiliser la puissance légale des DRM pour punir les détracteurs, à quel moment autoriser une critique.
« Divulgation responsable selon nos règles,
ou bien c’est la prison »
Ils ont appelé ça la divulgation responsable, mais elle est loin de celle qu’on voit aujourd’hui. En pratique, les entreprises font les yeux doux aux chercheurs en sécurité pour qu’ils communiquent leurs découvertes à des firmes commerciales avant de les rendre publiques. Leurs incitations vont de la récompense financière (bug bounty), à un système de classement qui leur assure la gloire, ou encore l’engagement de donner suite aux divulgations en temps opportun, plutôt que de croiser les doigts, de s’asseoir sur les défauts fraîchement découverts et d’espérer que personne d’autre ne les redécouvrira dans le but de les exploiter.
La tension qui existe entre les chercheurs indépendants en sécurité et les grandes entreprises est aussi vieille que l’informatique. Il est difficile de protéger un ordinateur du fait de sa complexité. La perfection est inatteignable. Garantir la sécurité des utilisateurs d’ordinateurs en réseau nécessite une évaluation constante et la divulgation des conclusions, afin que les fabricants puissent réparer leurs bugs et que les utilisateurs puissent décider de façon éclairée quels systèmes sont suffisamment sûrs pour être utilisés.
Mais les entreprises ne réservent pas toujours le meilleur accueil aux mauvaises nouvelles lorsqu’il s’agit de leurs produits. Comme des chercheurs ont pu en faire l’expérience — à leurs frais — mettre une entreprise face à ses erreurs peut être une question de savoir-vivre, mais c’est un comportement risqué, susceptible de faire de vous la cible de représailles si vous vous avisez de rendre les choses publiques. Nombreux sont les chercheurs ayant rapporté un bogue à une entreprise, pour constater l’intolérable durée de l’inaction de celle-ci, laissant ses utilisateurs exposés au risque. Bien souvent, ces bogues ne font surface qu’après avoir été découverts par ailleurs par des acteurs mal intentionnés ayant vite fait de trouver comment les exploiter, les transformant ainsi en attaques touchant des millions d’utilisateurs. Bien trop nombreux pour que l’existence de bogues puisse plus longtemps être passée sous silence.
Comme le monde de la recherche renâclait de plus en plus à leur parler, les entreprises ont été obligées de s’engager concrètement à ce que les découvertes des chercheurs soient suivies de mesures rapides, dans un délai défini, à ce que les chercheurs faisant part de leurs découvertes ne soient pas menacés et même à offrir des primes en espèces pour gagner la confiance des chercheurs. La situation s’est améliorée au fil des ans, la plupart des grandes entreprises proposant une espèce de programme relatif aux divulgations.
Mais la raison pour laquelle les entreprises donnent des assurances et offrent des primes, c’est qu’elles n’ont pas le choix. Révéler que des produits sont défectueux n’est pas illégal, et donc les chercheurs qui mettent le doigt sur ces problèmes n’ont aucune obligation de se conformer aux règles des entreprises. Ce qui contraint ces dernières à faire preuve de leur bonne volonté par leur bonne conduite, des promesses contraignantes et des récompenses.
Les entreprises veulent absolument être capables de déterminer qui a le droit de dire la vérité sur leurs produits et quand. On le sait parce que, quand elles ont une occasion d’agir en ce sens, elles la saisissent. On le sait parce qu’elles l’ont dit au W3C. On le sait parce qu’elles ont exigé ce droit comme partie intégrante du paquet DRM dans le cadre EME.
De tous les flops du processus DRM au sein du W3C, le plus choquant a été le moment où les avocats historiques du Web ouvert ont tenté de convertir un effort de protection des droits des chercheurs à avertir des milliards de gens des vulnérabilités de leurs navigateurs web en un effort visant à conseiller les entreprises quant au moment où renoncer à exercer ce droit. Un droit qu’elles n’ont que grâce à la mise au point des DRM pour le Web par le W3C.
Les DRM sont le contraire de la sécurité
Depuis le début de la lutte contre les DRM au W3C, on a compris que les fabricants de DRM et les entreprises de médias qu’elles fournissent n’étaient pas là pour protéger le droit d’auteur, mais pour avoir une base légale sur laquelle asseoir des privilèges sans rapport avec le droit d’auteur. On savait aussi que les DRM étaient incompatibles avec la recherche en sûreté : puisque les DRM dépendent de l’obfuscation (NdT: rendre illisible pour un humain un code informatique), quiconque documente comment les DRM marchent les empêche aussi de fonctionner.
C’est particulièrement clair à travers ce qui n’a pas été dit au W3C : quand on a proposé que les utilisateurs puissent contourner les DRM pour générer des sous-titres ou mener des audits de sécurité, les intervenants se demandaient toujours si c’était acceptable, mais jamais si c’était possible.
Il faut se souvenir que EME est supposé être un système qui aide les entreprises à s’assurer que leurs films ne sont pas sauvegardés sur les disques durs de leurs utilisateurs et partagés sur Internet. Pour que ça marche, cela doit être, vous savez, compliqué.
Mais dans chaque discussion pour déterminer quand une personne peut être autorisée à casser EME, il était toujours acquis que quiconque voulait le faire le pouvait. Après tout, si vous cachez des secrets dans le logiciel que vous donnez aux mêmes personnes dont vous voulez cacher les secrets, vous allez probablement être déçu.
Dès le premier jour, nous avons compris que nous arriverions à un point où les défenseurs des DRM au W3C seraient obligés d’admettre que le bon déroulement de leur plan repose sur la capacité à réduire au silence les personnes qui examineront leurs produits.
Cependant, nous avons continué à espérer : une fois que cela sera clair pour tout le monde, ils comprendront que les DRM ne peuvent coexister pacifiquement avec le Web ouvert.
Le succès des DRM au W3C est une parabole de la concentration des marchés et de la fragilité du Web ouvert. Des centaines de chercheurs en sécurité ont fait du lobbying au W3C pour protéger leur travail, l’UNESCO a condamné publiquement l’extension des DRM au Web, et les nombreuses crypto-monnaies membres du W3C ont prévenu que l’utilisation de navigateurs pour des applications critiques et sûres, par exemple pour déplacer les avoirs financiers des gens, ne peut se faire que si les navigateurs sont soumis aux mêmes normes de sécurité que les autres technologies utilisées dans nos vies (excepté les technologies DRM).
Il ne manque pas de domaines d’activités qui veulent pouvoir contrôler ce que leurs clients et concurrents font avec leurs produits. Quand les membres du Copyright Office des États-Unis ont entendu parler des DRM en 2015, il s’agissait pour eux des DRM dans des implants médicaux et des voitures, de l’équipement agricole et des machines de votes. Des entreprises ont découvert qu’ajouter des DRM à leurs produits est la manière la plus sûre de contrôler le marché, une façon simple et fiable de transformer en droits exclusifs les choix commerciaux pour déterminer qui peut réparer, améliorer et fournir leurs produits .
Les conséquences néfastes sur le marché économique de ce comportement anticoncurrentiel sont faciles à voir. Par exemple, l’utilisation intempestive des DRM pour empêcher des magasins indépendants de réparer du matériel électronique provoque la mise à la poubelle de tonnes de composants électroniques, aux frais des économies locales et de la possibilité des clients d’avoir l’entière propriété de leurs objets. Un téléphone que vous recyclez au lieu de le réparer est un téléphone que vous avez à payer pour le remplacer – et réparer crée beaucoup plus d’emplois que de recycler (recycler une tonne de déchets électroniques crée 15 emplois, la réparer crée 150 emplois). Les emplois de réparateurs sont locaux et incitent à l’entrepreneuriat, car vous n’avez pas besoin de beaucoup de capital pour ouvrir un magasin de réparations, et vos clients voudront amener leurs objets à une entreprise locale (personne ne veut envoyer un téléphone en Chine pour être réparé – encore moins une voiture !).
Mais ces dégâts économiques sont seulement la partie émergée de l’iceberg. Des lois comme le DMCA 1201 incitent à l’utilisation de DRM en promettant de pouvoir contrôler la concurrence, mais les pires dommages des DRM sont dans le domaine de la sécurité. Quand le W3C a publié EME, il a légué au Web une surface d’attaque qu’on ne peut auditer dans des navigateurs utilisés par des milliards de personnes pour leurs applications les plus risquées et importantes. Ces navigateurs sont aussi l’interface de commande utilisée pour l’Internet des objets : ces objets, garnis de capteurs, qui peuvent nous voir, nous entendre, et agir sur le monde réel avec le pouvoir de nous bouillir, geler, électrifier, blesser ou trahir de mille façons différentes.
Ces objets ont eux-mêmes des DRM, conçus pour verrouiller nos biens, ce qui veut dire que tout ce qui va de votre grille-pain à votre voiture devient hors de portée de l’examen de chercheurs indépendants qui peuvent vous fournir des évaluations impartiales et sans fard sur la sécurité et de la fiabilité de ces appareils.
Dans un marché concurrentiel, on pourrait s’attendre à ce que des options sans DRM prolifèrent en réaction à ce mauvais comportement. Après tout, aucun client ne veut des DRM : aucun concessionnaire automobile n’a jamais vendu une nouvelle voiture en vantant le fait que c’était un crime pour votre mécanicien préféré de la réparer.
Mais nous ne vivons pas dans un marché concurrentiel. Les lois telles que DMCA 1201 minent toute concurrence qui pourrait contrebalancer leurs pires effets.
Les entreprises qui se sont battues pour les DRM au W3C – vendeurs de navigateurs, Netflix, géants de la haute technologie, l’industrie de la télévision par câble – trouvent toutes l’origine de leur succès dans des stratégies commerciales qui ont, au moment de leur émergence, choqué et indigné les acteurs du secteur déjà établis. La télévision par câble était à ses débuts une activité qui retransmettait des émissions et facturait ce service sans avoir de licence. L’hégémonie d’Apple a commencé par l’extraction de cédéroms, en ignorant les hurlements de l’industrie musicale (exactement comme Firefox a réussi en bloquant les publicités pénibles et en ignorant les éditeurs du web qui ont perdu des millions en conséquence). Bien sûr, les enveloppes rouges révolutionnaires de Netflix ont été traitées comme une forme de vol.
Ces boîtes ont démarré comme pirates et sont devenus des amiraux, elles traitent leurs origines comme des légendes de courageux entrepreneurs à l’assaut d’une structure préhistorique et fossilisée. Mais elles traitent toute perturbation à leur encontre comme un affront à l’ordre naturel des choses. Pour paraphraser Douglas Adams, toute technologie inventée pendant votre adolescence est incroyable et va changer le monde ; tout ce qui est inventé après vos 30 ans est immoral et doit être détruit.
Leçons tirées du W3C
La majorité des personnes ne comprennent pas le danger des DRM. Le sujet est bizarre, technique, ésotérique et prend trop de temps à expliquer. Les partisans des DRM veulent faire tourner le débat autour du piratage et de la contrefaçon, qui sont des histoires simples à raconter.
Mais les promoteurs des DRM ne se préoccupent pas de ces aspects et on peut le prouver : il suffit de leur demander s’ils seraient partants pour promettre de ne pas avoir recours au DMCA tant que personne ne viole de droit d’auteur. On pourrait alors observer leurs contorsions pour ne pas évoquer la raison pour laquelle faire appliquer le droit d’auteur devrait empêcher des activités connexes qui ne violent pas le droit d’auteur. À noter : ils n’ont jamais demandé si quelqu’un pourrait contourner leurs DRM, bien entendu. Les DRM sont d’une telle incohérence technique qu’ils ne sont efficaces que s’il est interdit par la loi de comprendre leur fonctionnement. Il suffit d’ailleurs de les étudier un peu attentivement pour les mettre en échec.
Demandez-leur de promettre de ne pas invoquer le DMCA contre les gens qui ont découvert des défauts à leurs produits et écoutez-les argumenter que les entreprises devraient obtenir un droit de veto contre la publication de faits avérés sur leurs erreurs et manquements.
Ce tissu de problèmes montre au moins ce pour quoi nous nous battons : il faut laisser tomber les discussions hypocrites relatives au droit d’auteur et nous concentrer sur les vrais enjeux : la concurrence, l’accessibilité et la sécurité.
Ça ne se réglera pas tout seul. Ces idées sont toujours tordues et nébuleuses.
Voici une leçon que nous avons apprise après plus de 15 ans à combattre les DRM : il est plus facile d’inciter les personnes à prêter attention à des problèmes de procédure qu’à des problèmes de fond. Nous avons travaillé vainement à alerter le grand public sur le Broadcasting Treaty, un traité d’une complexité déconcertante et terriblement complexe de l’OMPI, une institution spécialisée des Nations Unies. Tout le monde s’en moquait jusqu’à ce que quelqu’un dérobe des piles de nos tracts et les dissimule dans les toilettes pour empêcher tout le monde de les lire. Et c’est cela qui a fait la Une : il est très difficile de se faire une idée précise d’un truc comme le Broadcast Treaty, mais il est très facile de crier au scandale quand quelqu’un essaie de planquer vos documents dans les toilettes pour que les délégués ne puissent pas accéder à un point de vue contradictoire.
C’est ainsi qu’après quatre années de lutte inefficace au sujet des DRM au sein du W3C, nous avons démissionné ; c’est alors que tout le monde s’est senti concerné, demandant comment résoudre le problème. La réponse courte est « Trop tard : nous avons démissionné, car il n’y a plus rien à faire ».
Mais la réponse longue laisse un peu plus d’espoir. EFF est en train d’attaquer le gouvernement des États-Unis pour casser la Section 1201 du DMCA. Comme on l’a montré au W3C, il n’y a pas de demande pour des DRM à moins qu’il y ait une loi comme le DMCA 1201. Les DRM en soi ne font rien d’autre que de permettre aux compétiteurs de bloquer des offres innovantes qui coûtent moins et font plus.
Le Copyright Office va bientôt entendre des nouveaux échos à propos du DMCA 1201.
Le combat du W3C a montré que nous pouvions ramener le débat aux vrais problèmes. Les conditions qui ont amené le W3C à être envahi par les DRM sont toujours d’actualité et d’autres organisations vont devoir faire face à cette menace dans les années à venir. Nous allons continuer à affiner notre tactique et à nous battre, et nous allons aussi continuer à rendre compte des avancées afin que vous puissiez nous aider. Tout ce que nous demandons est que vous continuiez à être vigilant. Comme on l’a appris au W3C, on ne peut pas le faire sans vous.
Avancer ensemble vers la contribution…
Contribuer, oui, mais comment ? Comment susciter des contributions, les accueillir, les dynamiser, lever les obstacles et les blocages de tous ordres ?
Tel a été le questionnement à l’origine du Fabulous Contribution Camp qui s’est déroulé à Lyon, du 24 au 26 novembre dernier, à l’initiative de La Quadrature et de Framasoft. Toutes les personnes qui ont participé ont eu à cœur d’identifier les difficultés honnêtement mais aussi de proposer des pistes et des pratiques pour les surmonter…
Pour en témoigner, nous donnons la parole aujourd’hui à Maiwann qui est UX designer et que nous avions invitée. L’article ci-dessous est la simple republication de son compte-rendu sur son blog. Ses observations, ses réactions et ses chouettes sketchnotes font véritablement plaisir (bientôt peut-être d’autres billets des participants?) et nous indiquent des voies qui sont déjà celles de Contributopia.. C’est un début prometteur, parions que beaucoup d’associations pourront en tirer profit et continuer l’exploration de la contribution positive.
Fabulous Contribution Camp
Pour finir ce mois de novembre en beauté, j’ai été invitée par Framasoft à participer au Fabulous Contribution Camp qu’ils co-organisaient avec La Quadrature du Net. Je suis donc partie à Lyon pour rencontrer des contributeur·ice·s de tous horizons (et pas seulement de la technique !) pour parler des outils et de comment aider celleux qui le souhaitent à contribuer plus simplement.
Un petit état des lieux
Pyg le disait lors du Capitole du Libre (dans la conférence Contributopia que vous pouvez retrouver ici), la majorité des projets de logiciel libre sont soutenus par très peu (voire pas) de contributeur·ice·s. L’exemple le plus marquant est celui des pads (une alternative à GoogleDocs permettant d’écrire collaborativement en ligne): Sur l’année dernière, il n’y a pas une seule personne ayant réalisé plus de 50 contributions, alors que le logiciel est très populaire !
C’est assez inquiétant, et en même temps pour avoir déjà échoué personnellement, parfois On a l’envie de contribuer et on y arrive pas. Ce qui est quand même assez comique lorsqu’on voit à quel point le logiciel libre a besoin encore et toujours de personnes volontaires !
J’avais donc hâte de me joindre à des groupes de réflexion sur le sujet afin d’identifier les problématiques et envisager des pistes de solution tout au long du FCC. Autant vous dire que tout le monde s’est transformé·e·s en designer pour concevoir une meilleure expérience contributeur·ice (Peut-on envisager de dire des CX Designer qui au lieu de signifier Customer eXperience sera notre Contributor eXperience Designer ? ^.^ )
FCC c’est parti !
Le FCC avait lieu à Grrrnd Zero, un lieu au caractère très affirmé, où les murs sont recouverts d’illustrations, près d’un immense chantier participatif destiné à devenir à la fois salle de concert, d’enregistrement et atelier de bricolage/dessin… Nous nous sommes fait accueillir avec un petit déjeuner fabuleux, cette première journée démarrait vraiment bien !
Après un icebreaker rigolo nous demandant de nous regrouper d’abord par provenance géographique (mais comment font les nomades ?), ensuite par coiffure, ensuite par système d’exploitation préféré (oui on était un peu chez les geeks quand même) et enfin par notre engagement associatif principal, nous nous sommes lancés sur des ateliers collaboratifs, animés par les enthousiastes Meli et lunar !
Failosophy : Identifier les problèmes
Pour démarrer, nous nous sommes regroupés par 4 et avons raconté chacun une expérience marquante où notre envie de contribuer s’est soldée par un fail. Nous notions les différentes problématiques rencontrées sur des post-its avant de toutes les regrouper sur un grand mur pour avoir une vue d’ensemble des cas les plus fréquents. Ensuite, nous avons collaborativement trié les post-it ce qui prend “étrangement toujours 8 minutes peu importe le nombre de post-its ou de personne” d’après Lunar… Il faut dire qu’il avait raison 😉
De grandes catégories regroupent les post-its et font apparaître des motifs récurrents. Ceux que je retiens (car ils me font écho) :
La difficulté d’identifier un interlocuteur référent pour s’intégrer au projet
La peur de demander « Comment faire »
La peur de ne pas être assez doué·e / de dire des « choses bêtes »
Ne pas savoir par où commencer
La peur de ne pas s’intégrer à la communauté
Le manque de temps
La difficulté de déléguer à d’autres un projet qu’on a toujours porté
Le fait de ne pas avoir réussi à créer une communauté autour d’un projet
Ne pas connaître la ligne de route d’un projet
Ne pas savoir comment exprimer les besoins de contribution pour que les intéressé·e·s les comprennent
J’ai la sensation qu’un grand nombre de ces problèmes peuvent être résolus en:
Listant clairement les besoins de contributions, avec les compétences nécessaires, via une interface plus facile d’accès qu’un github (qui est réellement anxiogène pour les non-développeur·euse·s)
Désignant une personne accueillante comme point d’entrée pour les nouveaux·lles arrivant·e·s, à laquelle il sera facile de s’adresser, et qui saura aiguiller chacun·e vers des tâches simples pour découvrir le projet.
Cela se recoupe avec les discussions du Capitole du Libre, ce qui donne la sensation que nous sommes sur la bonne voie et que les hypothèses que j’ai entendues la semaine dernière sont des solutions à des problèmes récurrents pour les contributeur·ice·s !
Étude de cas : 6 projets appelant à la contribution
Dans la phase suivante, pour s’imprégner un peu de ce qui se fait parmi les projets nécessitant contribution, nous avons eu le droit à la présentation de:
Exodus, une plateforme qui analyse les applications Android et liste les logiciels traquant notre activité qu’elle y trouve.
La Revue de Presse de la Quadrature du Net, permettant de soumettre des articles à la revue de presse de façon collaborative.
Diaspora, un réseau social décentralisé assez proche de la configuration initiale de facebook.
FAI Maison, un fournisseur d’accès associatif et nantais, qui propose le prix libre (ou contribution consciente)
Le PiPhone, une plateforme de La Quadrature du Net permettant d’avoir accès à des numéros de députés afin de les appeler pour les encourager à soutenir (ou non) une loi, en proposant un set d’arguments et un retour d’expérience après l’appel.
FramaForm, une des alternatives de Dégooglisons Internet lancée par Framasoft, que Pyg a développée seul (!) en 15 jours (!!!). Avec le souci notamment que le logiciel permet plein de choses différentes mais que les options sont difficiles à trouver.
Le tour d’horizon permet de voir que si chaque projet recherche à fédérer une communauté de contribution, ils sont tous très différents et n’intéressent sans doute pas du tout les même personnes. Les présentations étaient elles aussi très variées selon la personne, de celui qui démarre par l’aspect technique à celui qui met tout de suite en avant les problématiques d’ergonomie. Bien sur, la présentation varie énormément selon les affinités et les problématiques rencontrées par chacun·e. Peut-être qu’avoir une description homogène (qui ne parte dans l’aspect technique que face à des personnes orientées technique) puis des pistes selon les compétences / envies de la personne en face serait à envisager ? (c’est un point que je laisse en suspens, mais il faut avouer qu’à force je suis rebutée par ceux qui m’expliquent immédiatement en quelle technologie est leur application alors que je suis très interessée par celleux qui ont des problématiques de conception 😉 )
Icebreaker rigolo
Petite recette: Prenez une feuille et écrivez en gros au marqueur ce dont vous avez envie de parler / un truc à apprendre à quelqu’un, montrez la feuille à tout le monde et formez un binôme avec une personne qui est intéressé·e par votre thème et a un thème qui vous intéresse (ou pas) !
Grodébat I
Après déjeuner (des lasagnes végétariennes à tomber <3) nous avons repris certaines catégories de problématiques listées le matin et nous sommes séparés en petits groupes pour déterminer:
C’est quoi le problème ?
Dans l’idéal, avec une baguette magique, qu’est-ce qu’on fait ?
Quelles solutions concrètes pour y arriver ?
Nous sommes arrivés à tout un tas de solutions pour nous mettre le pied à l’étrier:
Vision :
Créer un manifeste et créer des rencontres mêlant communauté de contributeur·ice·s et utilisateur·ice·s
Accès au savoir & Appropriation :
Formuler des avantages concurrentiels pour les marchés publics et rendre transparents les logiciels utilisés dans le service public
Sortir de l’entre-soi :
Trouver des métaphores pour expliquer sans être technique, lister les communautés avec des objectifs similaires mais des besoins différents.
Répartition des tâches :
Lister l’ensemble des tâches à faire et leur avancement.
Expression des besoins :
Lister & Publier les besoins de contribution en petites tâches, Créer un bouton “J’ai un problème” qui s’adresse à un humain (facilitateur ou UX designer)
Rapports de pouvoir :
Mettre et afficher un système de résolution des conflits.
Gestion du temps (et de l’argent) :
Mesurer le temps mis pour une tâche pour le prioriser dans le futur et compléter le financement par le don.
Accueil :
Avoir un·e référent·e du projet, co-rédiger une charte d’accueil “Comment accueillir les personnes”.
Toutes ces solutions qui sont autant de petits pas à mettre en œuvre m’ont beaucoup enthousiasmée : j’ai l’impression que le chemin est tout tracé pour réaliser de belles choses ensemble ! Nous avons d’ailleurs enchaîné avec de petits groupes de travail concrets permettant de débuter la rédaction d’une charte, designer un bouton “J’ai un problème” ou encore réfléchir à une plateforme listant les besoins de contribution.
Tout ça en une seule journée autant vous dire que nous étions lessivé·e·s à la fin, mais après un bon repas (préparé par les cuistots de Grrrnd Zero) il était temps de se coucher pour être fraî·che·s le lendemain !
C’est reparti pour un tour !
C’est avec une fraîcheur toute relative que nous avons entamé la seconde journée du FCC. La fatigue est là, mais la bonne humeur et l’enthousiasme général donnent vraiment envie de finir le week-end en beauté. Nous entamons un tour de météo avec pas mal de personnes dans le brouillard du matin, mais très vite nous faisons chauffer les méninges collectivement.
Contributeur·ice·s, où êtes-vous ?
Nous démarrons par une séance de « boule de neige » où nous sommes invité·e·s à lister les endroits où, demain, nous pourrions aller pour parler du logiciel libre et trouver de nouvelles personnes pour contribuer ! Sur un autre tas, nous écrivons plutôt ce qui nous empêche de le faire actuellement.
Je liste personnellement mes précédentes écoles de design qui sont, à mon avis, des nids à designers motivé·e·s mais pour qui le monde du libre est inexistant (on a tendance à nous parler principalement de droit d’auteur et nous n’entendons jamais parler de licences libres). Pour y aller cependant, il me faut plus de connaissances sur les licences et une liste de projet dont ils pourraient s’emparer afin de commencer à contribuer rapidement.
À la fin nous collons tout nos post-it sur les murs et, comme a dit lunar: “Si chacun ramène 3 personnes, la prochaine fois on est 300.”. Il n’y a plus qu’à !
Gros Débat II : Le retour
Nous enchaînons sur des groupes de travail thématiques. Je rejoins celui qui aborde le sujet du financement, et y apprends sans surprise que les subventions demandent un investissement énorme (environ 1/3 du temps total de travail passé pour les demander) et que, si le fonctionnement grâce aux dons permet beaucoup plus de liberté, il est soumis à des règles strictes, notamment au fait qu’on ne peut pas donner de contrepartie en échange d’un don, qui doit être fait uniquement pour soutenir le travail passé et à venir de l’association (dans les grandes lignes).
Le monde des financements a l’air très nébuleux, ce qui nous fait envisager de rechercher des contributeur·ice·s s’y connaissant en financement comme l’on en rechercherait en design ou en admin sys !
Les autres groupes ont pour leur part envisagé :
Accueil :
Montrer de l’intérêt aux personnes qui arrivent, lister les besoins afin qu’iels puissent s’en emparer.
Discutons ensemble :
Diversifier les compétences en listant les besoins (les solutions se regroupent, chouette !), ne pas imposer des outils libres aux futurs utilisateur·ice·s mais partir de leurs problèmes plutôt (on dirait bien une démarche de conception centrée utilisateur·ice \o/ )
Rencontrer les utilisateur·ice·s :
Avoir des relais au sein de l’association ou se greffer à une rencontre existante afin de faciliter les échanges, demander à des UX Designers de se joindre aux rencontres et motiver certains devs à venir voir les tests utilisateurs.
Comment on garde le lien post-FCC :
Avoir une plateforme ou l’on puisse mettre des photos, un article de blog (collaboratif ?) récapitulant le week-end, et au-delà, une plateforme listant les besoins de contribution (oui, encore, chouette !)
La machine infernale !
Après le repas composé de pizzas maison (c’est vraiment sympa Grrrnd Zero), nous nous lançons dans la machine infernale : une première personne se place et commence à enchaîner un son et un geste, de façon répétitive. Une seconde personne la rejoint et va elle aussi réaliser son geste, et chacun va à son tour rejoindre la machine infernale, en répétant indéfiniment son geste et son son jusqu’à ce que… la machine s’emballe ! C’était un petit jeu très chouette et revigorant après la phase digestive !
Gros Débat III
Pour ce troisième groupe de réflexion, je rejoins pyg qui a envie de réunir des associations afin de les informer sur le logiciel libre, qui leur plaît pour des raisons évidentes de prix, mais aussi de valeurs ! Cependant le numérique est un domaine assez vaste et pour des assos qui ne s’y connaissent pas, il y a besoin de faire de l’éducation aux usages et à ce que cela engendre d’utiliser tel ou telle logiciel ou application.
Le groupe fourmille d’idées, je retiens pêle-mêle:
Il y a un besoin de sensibilisation, de démonstration des possibilités des logiciels libres, et d’accompagnement à la transition,
Les associations ont besoin d’indépendance, de communiquer et de collaborer
Les mettre en relation vis à vis de leurs besoins peut permettre une mise en commun de financement pour développer des logiciels ouverts et adaptés
Il faut aller voir les assos pour savoir ce dont elles ont besoin et ce qu’elles recherchent
Selon les retours, décider du format, plutôt conférence organisée ou Summer Camp très ouvert ?
Moi qui recherche à participer à des choses qui ont du sens, me voilà pile au bon endroit et j’en suis très heureuse ^.^
Ça sent la fin !
Enfin, pour finaliser le FCC, nous avons 4 catégories de post-it, à remplir puis à afficher au mur:
❤️ Ce que nous avons fait ce week-end et qui nous a plu !
🌟 Ce que j’ai envie de faire dès demain pour contribuer.
➡ Ce que je fais dans les prochains mois.
😊 Ce que j’ai envie que quelqu’un d’autre ici fasse (et chacun pouvait récupérer un post-it de ce type pour s’y engager)
Voici les miens :
Merci le FCC !
Ce Fabulous Contribution Camp a été une très bonne expérience : J’ai pu parler UX en long, en large et en travers, à des personnes qui se sont montrées à l’écoute de ce que j’avais à leur raconter (et ça ça fait plaisir !). Les différentes solutions énoncées, avec des pistes concrètes de réalisation pour se lancer rapidement me donnent des ailes, et j’espère que cette motivation ne va pas retomber de sitôt !
Je vous tiendrai au courant de mes avancées dans le monde du libre et de la contribution, en tout cas je remercie Framasoft de m’avoir permis de venir partager un week-end à Lyon avec eux à parler et rêver du futur du numérique !
Pour finir, voici les sketchnotes de ce week-end collaboratif. Prenez soin de vous 🙂
Griffonné le 30 novembre 2017
PeerTube : les réponses à vos questions techniques !
— J’ai actuellement un petit serveur de 10 Go, mais qui grossira l’année prochaine, qui tourne sous Archlinux. Quelle méthode utiliser pour partager une partie de mes ressources pour le projet peertube ?
Pour l’instant le projet n’est pas encore en bêta donc attendre quelques mois. 😉
— Qu’utilisez-vous, python, ruby, asm… 🙂 ???
Le projet tourne via NodeJS/PostgreSQL, un peu de Shell et aura besoin de ffmpeg pour générer les miniatures et faire le transcoding (qui est en option).
Guyou
— Est-ce que le pari c’est que tout le monde regarde la même vidéo en même temps ? Mon usage de Youtube consiste à regarder, de temps à autre, des vidéos de 15-30 minutes. Mais ces vidéos ne font pas forcément l’objet du buzz du moment. Parfois, j’imagine même que Youtube doit commencer à fouiller son disque pour la retrouver.
Sinon, on va vite se retrouver avec de petits serveurs qui reçoivent plein de demandes pour différentes vidéos et qui se retrouvent vite dans l’impossibilité de servir tout le monde à cause de leur propre bande passante limitée.
Tu as tout à fait raison. Pour l’instant l’aspect P2P limite le facteur bande passante mais c’est pas une recette miracle : si 1000 personnes regardent 1000 vidéos différentes le serveur tombera.
— Est-il envisagé/envisageable de faire évoluer le modèle pour que chaque serveur du réseau puisse à son tour se joindre au réseau P2P d’une vidéo demandée par l’un de ses utilisateurs ?
À court terme il n’est pas prévu d’améliorer cet aspect. En revanche si la campagne de dons est un grand succès, on peut espérer que Framasoft continue de financer le projet pour ajouter de la redondance dans PeerTube → un autre serveur télécharge la vidéo puis la seed pour aider le serveur d’origine.
Du coup tout dépendra des donateurs. 🙂
ropoussiere
— On parle de fédération mais grosso-modo, j’imagine qu’il y aura une seule fédération non ? (comme Diaspora ou Mastodon)
Ce sera une fédération comme Mastodon, oui, à l’exception que ce seront les administrateurs de serveurs qui choisiront quel(s) serveur(s) suivre. Ça leur donne le contrôle sur les vidéos indexées (et donc affichées) sur leur serveur. Il sera possible de copier les « follows » d’autres serveurs bien sûr, sinon ça risquerait vite d’être pénible.
— Je suis jeune hébergeur, comment je trouve des amis qui veulent bien héberger les vidéos de mon instance pour la soulager / comment je suis tenu au courant des vidéos qui viennent d’être ajoutées sur les instances de mes amis, ça peut se faire automatiquement ?
Il n’y a pas pour l’instant de système de redondance donc pas moyen de choisir quelles vidéos tu veux redonder. À l’heure actuelle les vidéos « uploadées » sur ton serveur restent sur ton serveur, et seul ce dernier possède les fichiers physiques.
— Je viens de regarder une vidéo. À partir de quel moment je cesse de la partager ? (quand je quitte le site ? quand je ferme mon navigateur ? quand je redémarre mon pc ?)
Au moment où tu quittes la page de la vidéo (là où y’a le lecteur).
— On peut supposer que Framatube sera une instance PeerTube très majoritairement utilisée et qu’une très grande partie des utilisateurs ajouteront leurs vidéos via Framatube sans trop se poser de questions. Est-ce qu’un mécanisme est prévu pour téléverser la vidéo directement sur une autre instance pour ne pas remplir le disque dur de Framatube de vidéos de chats en quelques jours ?
À voir si Framatube ouvre et s’ils ouvrent à tout le monde pour n’importe quelles vidéos (je ne peux pas personnellement répondre), mais non il n’y a pas de mécanisme pour téléverser des vidéos sur d’autres instances. Par contre on peut fermer les inscriptions lorsqu’on atteint un certain nombre d’utilisateurs, et mettre un quota en octets par utilisateur. Si tu fais bien ton calcul tu peux donc gérer ton serveur sans remplir totalement le disque. Après à toi de voir si tu veux ouvrir d’autres instances pour accueillir de nouveaux utilisateurs.
— Suggestion : une interface pour ajouter des sous-titres ?
— Bonjour, l’installation sur un raspberry3 est-elle possible ? Viable ?
J’ai jamais testé mais « normalement » ça devrait être possible. Les seuls points bloquants pourraient être la compilation de certains modules Node (mais y’en a pas tant que ça).
— Est il possible d’utiliser un autre répertoire pour les médias ? Où sont ils stockés ?
Il stocke les vidéos dans le dossier spécifié dans la configuration.
JonathanMM
— Pourquoi ne pas se reposer sur le protocole torrent, qui propose déjà un catalogue et un réseau déjà pas mal ? Le lecteur vidéo ne serait alors qu’un client comme un autre, et le serveur servirait à la fois de serveur de trackers (et même aussi d’un client comme un autre, histoire d’augmenter les peers).
Ce serait bien mais malheureusement :
la plupart des vidéos sont dans un format incompatible avec le Web (.avi, .mkv etc.) ;
le navigateur ne peut se connecter aux autres pairs que via WebRTC, pas directement en TCP/UDP. Donc ton navigateur ne peut pas se connecter à un client Transmission/uTorrent par exemple ;
ça reste le protocole BitTorrent mais sur WebRTC, donc si les principales librairies de torrent ajoutent le support de WebRTC il sera possible de « seeder » une vidéo via un client torrent classique pour ton navigateur. Une issue est en cours pour suivre les évolutions d’implémentation de WebRTC dans les principales librairies torrent ;
encore une fois l’aspect P2P dans PeerTube c’est du BitTorrent, donc chaque serveur a effectivement un tracker (ton navigateur s’y connecte via websocket).
JonathanMM
— Ok, je comprends mieux […] Après, un truc qui je pense pourrait-être sympa serait d’avoir pour l’admin un système d’ajout rapide d’une vidéo sur le serveur, où on balance un lien ou un fichier torrent, et le système regarde si la vidéo est OK ou pas avant de la mettre sur son réseau. Ça permettrait d’avoir déjà une base de sources pour le jour où les libs utiliseront le WebRTC. Voir ça permettrait aux serveurs de s’échanger entre eux des vidéos ?
Yep, un import via torrent ou via URL serait utile. Un import via YouTube serait aussi le top.
Aitua
— Faut-il avoir son ordinateur connecté 24h/24 pour que la vidéo que l’on héberge soit disponible à tout moment ? Ou le serveur fait le relais ?
Le serveur fait relais, c’est lui qui s’occupe de constamment « seeder » la vidéo pour qu’elle soit toujours disponible. Pour info, il seed la vidéo via HTTP (ce qui ne demande aucun effort constant) via l’extension WebSeed du protocole BitTorrent
CamilleKaze57
— Est-ce que Peertube utilisera le protocole ActivityPub pour se fédérer avec Mastodon et GnuSocial ? Une vidéo pourrait apparaître sous la forme d’une publication et les commentaires comme des réponses. Je rappelle qu’Activitypub est soutenu par le W3C et a vocation à devenir un standard. En plus pouvoir se connecter avec son compte Mastodon ce serait génial !
Donc, oui, en théorie on pourra se fédérer avec Mastodon et consorts (ça demandera quand même des adaptations au niveau code), et c’est tout ce qu’on espère. 🙂
Olivier Massain a profité de notre foire aux questions pour proposer son aide sur le design de PeerTube : ça va péter la classe !
« Ça ressemblerait pas un peu à… »
sossa
— Connaissez-vous BitChute qui fonctionne sur exactement le même principe ? Y-a-t-il un problème inhérent à BitChute qui vous pousserait à créer un autre outil ?
BitChute n’est pas libre, pas installable sur son serveur et pas fédéré.
Le seul point commun avec PeerTube est qu’il utilise WebTorrent, afin de soulager la bande passante pour ses propres besoins.
sossa
— OK, c’est très clair, merci ! Il est vrai que je l’avais regardé à son lancement, où ils parlaient d’ouverture et « d’installabilité », et deux ans après, rien n’a bougé, ce qui est au minimum suspicieux.
hyamanieu
— Je me demandais si vous aviez remarqué qu’il y a un projet similaire, dont le premier commit date d’août 2015 (quelques mois avant vous), et qui a beaucoup plus d’élan? Ils sont toujours en bêta (vous alpha), mais ils ont déjà ramené beaucoup de YouTubers anglophones et bientôt des francophones : lbry
Je ne connaissais pas lbry, que je viens de découvrir.
Si j’ai bien compris il s’agit plus d’un protocole, s’utilisant via un démon que tu lances et qui écoute sur un port particulier ? Et ils veulent utiliser un plugin pour pouvoir être disponible via le web. Le projet veut faire de la décentralisation avec un système de financement pour les créateurs.
PeerTube quant à elle est une application web donc difficilement comparable à lbry. De plus notre idée est de pouvoir faire communiquer différentes plateformes web (MediaGoblin, Mastodon etc) via ActivityPub, pas de s’enfermer dans un protocole particulier (que je ne remets pas en question, hein :)).
hyamanieu
— En effet, il s’agit d’un protocole. Quelles que soient les solutions techniques envisagées, ce qui compte est l’utilisation finale. Mais je ne pense pas que ça cause de grands problèmes la compétition, peut-être même l’inverse. Sur des projets open source c’est un peu dommage, c’est tout.
Je suis bien d’accord, c’est pour ça qu’on migre le protocole de fédération vers ActivityPub pour avoir une coopération entre plateformes différentes plutôt que de la compétition.
www
— Que pensez-vous de DTube ? (basé sur STEEM et IPFS)
Je n’en pense pas grand-chose, je ne connais pas assez les deux technos.
J’ai juste l’impression qu’IPFS n’est pas tout à fait prêt (d’où leur ajout de WebTorrent en secours si j’ai bien compris) et assez complexe (faut mettre en place des passerelles etc.).
Il ne me semble pas que DTube soit libre non plus.
Mais je suis le projet, c’est assez innovant comme manière de fonctionner.
Avant de vous partager ces échanges, voici un petit résumé de la situation 😉
Expliquer Framatube en 3mn
Si vous n’avez pas encore entendu parler de Framatube et de PeerTube (ou si vous voulez en parler autour de vous), on a une astuce ! Hélène Chevallier, journaliste à France Inter, nous a interviewé et a résumé les enjeux et notre démarche dans sa chronique « C’est déjà demain » du 28 novembre dernier, que voici :
Pour rappel, n’hésitez pas à nous soutenir dans le financement de PeerTube et dans l’ensemble de nos actions, en faisant un don.
Mais revenons-en au propos de cet article : vos questions ! Nous avons regroupé les réponses à des questions plus techniques dans un autre article sur ce blog ^^. Sauf mention contraire, toutes les réponses sont de Chocobozzz, le développeur que nous avons accueilli dans notre équipe salariée afin qu’il puisse finaliser le code de PeerTube. De même, la plupart des questions ont été raccourcies ou reformulées pour plus de lisibilité, mais l’intégralité des échanges se trouve sur notre forum !
Olivier Massain a profité de notre foire aux questions pour proposer son aide sur le design de PeerTube : ça va péter la classe !
Quels contenus, quelles vidéos…?
TeemoT
— Je voudrais en savoir plus sur le type de contenus qui y seraient hébergés, n’importe quelle vidéo pourrait y être ? Ou y a-t-il des règles à respecter ?
Pouhiou souhaite répondre ici :
À vrai dire, cela dépendra de chaque hébergement PeerTube.
Car, et c’est important de le souligner : a priori, Framasoft n’hébergera pas vos vidéos sur Framatube.
En effet, notre but est que se monte une fédération d’instances PeerTube à la fois indépendantes et dans une entraide commune. Or, si nous ouvrons notre instance de PeerTube (qui sera donc Framatube) aux vidéos de tout le monde, la facilité fera que les vidéos seront postées chez nous et de ne pas chercher à créer sa propre instance ou a se regrouper par communauté d’intérêts.
Du coup, nous serons là pour aider et accompagner les personnes, associations, collectifs de vidéastes, lieux de formation, médias, etc. qui veulent monter leur instance et se fédérer. Mais ce sera à chacune de ces instances de choisir quelle porte d’entrée vers PeerTube elle veut être, donc par exemple de déterminer leurs conditions générales d’utilisation.
Du coup, le type de contenus vidéos dépendra forcément des personnes qui se regrouperont pour héberger des vidéos sur leurs instances et des vidéos qu’elles y accepteront ;).
arthurrambo
— Qu’en est-il des vidéos prônant l’homophobie, l’antisémitisme et le racisme ? Seront-elles supprimées comme sur YouTube ? Quelles conséquences pourra-t-il y avoir sur le créateur ?
Une vidéo peut-être signalée par un utilisateur. Le signalement va à l’administrateur/modérateurs du serveur sur lequel est enregistré l’utilisateur, plus à l’administrateur/modérateurs du serveur qui possède la vidéo.
C’est donc à eux d’évaluer s’ils veulent ou non supprimer la vidéo (puis potentiellement l’utilisateur) :
Si le serveur détient la vidéo elle est supprimée en local puis sur l’ensemble du réseau (par fédération) ;
Si le serveur ne détient pas la vidéo elle est simplement supprimée en local.
Pyg se permet d’ajouter :
À la réponse de Chocobozzz concernant l’outil, j’ajoute celle de la loi.
En effet, trop peu de contenus contenant des discours de haine sont signalés. Certes, les procédures sont longues, mais trop peu de gens les utilisent, ce qui a pour conséquence de laisser croire que la plateforme (Twitter, Facebook, ou ici une instance PeerTube) est « le » interlocuteur pour signaler les contenus.
Sur Mastodon, on a bien vu que beaucoup s’étaient crus, au départ, dans un nouveau Far West (« c’est mon instance, je fais ce que je veux »). Il faut rappeler la loi, encore et encore, et la faire vivre, car c’est elle qui est l’un des principaux supports du « vivre ensemble ».
Il va de soi, mais ça va mieux en le disant, que sur notre future instance PeerTube, aucun propos contraire à ces lois ne saura être toléré.
JonathanMM
— Est ce qu’à l’ouverture du service, il est prévu des vidéos de gens connus (style gros youtubeurs), histoire qu’il y ait déjà un peu de contenu grand public et que ça ne part pas de presque rien ?
Pouhiou a un début de réponse :
Pour l’instant, peu de choses sont prévues : on vient tout juste d’annoncer le projet !
L’idée est justement de commencer à entrer en contact avec divers collectifs pour voir s’ils ont envie d’avoir une instance PeerTube, de s’approprier leurs moyens de diffusion. Nous discutons actuellement avec des associations, des fédérations, et avec quelques vidéastes pour voir si et comment nous pourrions les accompagner. Mais ne mettons pas la charrue avant les bœufs : il faut d’abord avoir un code fonctionnel, une interface accueillante, bref un outil qui soit facile à installer et utiliser.
Du coup, ce travail d’accompagnement se fera entre janvier et février, et nous enjoignons tout groupe souhaitant devenir son propre hébergeur de vidéos (même si c’est en parallèle d’une chaîne YouTube, au moins au début) à nous contacter pour qu’on puisse les aider ;).
Mais soyons francs : en mars 2018, ce sera le début d’un nouveau réseau d’hébergement de vidéos, et non un bouquet final !
acryline
— J’aimerais savoir si un jour Peertube pourra permettre le live streaming ?
Ça risque d’être compliqué, car le torrent fonctionne sur des fichiers finis immuables.
Certains ont essayé en générant en boucle un fichier torrent toutes les x secondes, puis en l’envoyant aux autres clients. Je n’ai pas testé mais c’est plutôt ingénieux. Après est-ce que ça marche bien et efficacement, je ne sais pas parce que c’est un peu de la bidouille.
Au lieu d’utiliser BitTorrent on pourrait imaginer utiliser que la fédération de serveurs, on partagerait la bande passante entre les serveurs. Après ça ne reste qu’une idée. Mais c’est loin d’être pour tout de suite. 🙂
Oui, il y a possibilité d’incruster la vidéo dans n’importe quelle page web.
— Comment se comporte PeerTube quand il y a des accès simultanés depuis un même réseau intranet ?
Que ce soit via intranet ou internet il y utilisation de WebRTC, qui regardera s’il y a un moyen pour ces différents utilisateurs de s’échanger de la donnée. S’il y a possibilité (pare-feu/routeur sympa) ça sera fait automatiquement. Sinon ça passera simplement par HTTP sans notion de pair-à-pair.
buyaman
— Comment procéder pour une transition en douceur entre les plateformes actuelles et la vôtre ? Ex: je suis un vidéaste au contenu prolifique (1000 vidéos) en combien de temps je fais le transfert ?
Tout dépend de votre plate-forme actuelle, mais on aimerait ajouter une interface d’import (depuis YouTube notamment).
— Et serait-ce une transition abrupte ou en douceur (les deux plateformes utilisées le temps de la transition) ?
C’est à vous de décider 😉
Aitua;
— J’imagine que si le filtrage automatique est inscrit dans la loi européenne, les serveurs dans l’UE seraient obligés d’imposer un tel filtrage ?
Pouhiou a été invité à répondre :
Question très très intéressante, car elle montre que ce projet de loi n’est pensé que pour des plateformes centralisatrices de gros hébergeurs (qui ont les moyens de mettre en place de tels filtres) et pénalise de fait l’auto-hébergement ou l’hébergement mutualisé, tout en déconsidérant d’emblée les systèmes décentralisés ou distribués.
Déjà, il faut se dire qu’entre le fait que cela entre dans une loi/directive européenne, le fait d’avoir des décrets d’application, le fait que cela ne soit pas démonté par le conseil constitutionnel (j’avais lu quelque part que cette proposition avait toutes les chances d’être écartée à ce niveau)… Bref : on a le temps de voir venir !
Et la question finale : qu’est-ce qu’un filtre automatique ? S’il suffit d’analyser le texte donné en titre à la vidéo ou d’ajouter une case à cocher lors de l’upload « promis je respecte le copyright« , ça peut facilement être implémenté…
Bref, c’est une des raisons pour laquelle moi aussi je veux passer à PeerTube et ne plus avoir à subir ces filtrages !
Nous n’avons clairement pas les mêmes moyens que Google ! Illustration : CC-By-SA Emma Lidbury
Parlons sous…
choosebzh
— Je vais peut-être poser la question qui fâche, mais qu’en est-il des annonceurs? Certains vidéastes prolifiques pourront-ils en retirer une source de revenus? Même faible, bien sûr. Car être libriste, oui, mais faut vivre aussi. 🙂
Techniquement il n’est pas prévu d’ajouter de la pub.
Rien n’empêche pour le vidéaste d’incorporer une annonce dans sa vidéo (ça commence à se faire sur les autres plate-formes) même si ça a ses limites.
Il est probable qu’on ajoute la possibilité d’afficher des boutons Liberapay, Tipeee, Patreon, etc., en dessous de la vidéo. Mais ce n’est pas notre priorité pour l’instant.
Pouhiou se permet d’ajouter :
Sur la question des annonceurs, et en tant qu’ancien « youtubeur » qui connaît encore beaucoup de monde dans le milieu, j’ajoute une précision.
L’annonce publicitaire est un modèle de rémunération qui paye très très mal les vidéastes. Avec l’explosion des créations vidéos, les annonces sont payées de moins en moins, et on est bien loin du « 1€ pour 1000 vues » de 2013… C’est un modèle qui marche encore pour les très très très gros succès (des millions de vues sur plusieurs vidéos), ce qui représente une infime partie des vidéastes.
Actuellement, si un·e vidéaste veut se faire de l’argent avec de la pub, le meilleur moyen reste les partenariats et placements de produits.
Le modèle économique le plus efficace pour les « petit·e·s vidéastes » semble encore être le modèle du don (Tipee, Patreon, Liberapay) qui, s’il n’est pas intégré à PeerTube dès sa bêta, sera relativement facile à implémenter (parce que PeerTube est un logiciel libre).
Framasoft
Et tant que nous parlons sous, faisons un petit point sur le financement…
(oui, nous avons rajouté cette question nous-mêmes, c’est triché… mais cela nous permet de faire le point avec vous, en toute transparence)
Et Framasoft de s’auto-répondre :
Comme nous l’affichons sur le site présentant le projet Framatube, nous finançons le développement de PeerTube sur le budget de l’association, dont 90 % des revenus proviennent de vos dons.
En effet, sur les 90 000 € qu’il nous manque pour boucler notre budget 2018 :
instantané des dons 9 jours après le lancement de la campagne PeerTube.
À la rédaction de cet article, nous avons déjà récolté pas loin de 20 000 € en une semaine, ce qui est formidable, parce que vous êtes des personnes formidables (n’en doutez jamais) ! Néanmoins, rien n’est gagné et si nous ne voulons pas revoir nos ambitions à la baisse, il faudrait que nous atteignions cette barre des 90 000 € d’ici le 31 décembre.
Pour rappel, notre association étant reconnue d’intérêt général, tout don de contribuables français·es peut être déduit de leurs impôts sur les revenus. Ainsi, un don de 100 € vous reviendra, après déduction fiscale, à 34 €.
Sachez que, si nous dépassons cet objectif des 90 000 €, notre priorité sera de permettre à Chocobozzz de poursuivre le développement de PeerTube, et donc d’ajouter à cette solution des fonctionnalités très attendues (ce ne sont pas les idées qui manquent, juste les moyens ^^).
Depuis les années 1950 et l’apparition des premiers hackers, l’informatique est porteuse d’un message d’émancipation. Sans ces pionniers, notre dépendance aux grandes firmes technologiques aurait déjà été scellée.
Aujourd’hui, l’avènement de l’Internet des objets remet en question l’autonomisation des utilisateurs en les empêchant de « bidouiller » à leur gré. Pire encore, les modèles économiques apparus ces dernières années remettent même en question la notion de propriété. Les GAFAM et compagnie sont-ils devenus nos nouveaux seigneurs féodaux ?
Une traduction de Framalang : Relec’, Redmood, FranBAG, Ostrogoths, simon, Moutmout, Edgar Lori, Luc, jums, goofy, Piup et trois anonymes
Est-ce vraiment ainsi que se définissent maintenant nos rapports avec les entreprises de technologie numérique ? Queen Mary Master
Les appareils connectés à Internet sont si courants et si vulnérables que des pirates informatiques ont récemment pénétré dans un casino via… son aquarium ! Le réservoir était équipé de capteurs connectés à Internet qui mesuraient sa température et sa propreté. Les pirates sont entrés dans les capteurs de l’aquarium puis dans l’ordinateur utilisé pour les contrôler, et de là vers d’autres parties du réseau du casino. Les intrus ont ainsi pu envoyer 10 gigaoctets de données quelque part en Finlande.
En observant plus attentivement cet aquarium, on découvre le problème des appareils de « l’Internet des objets » : on ne les contrôle pas vraiment. Et il n’est pas toujours évident de savoir qui tire les ficelles, bien que les concepteurs de logiciels et les annonceurs soient souvent impliqués.
Dans mon livre récent intitulé Owned : Property, Privacy, and the New Digital Serfdom (Se faire avoir : propriété, protection de la vie privée et la nouvelle servitude numérique), je définis les enjeux liés au fait que notre environnement n’a jamais été truffé d’autant de capteurs. Nos aquariums, téléviseurs intelligents, thermostats d’intérieur reliés à Internet, Fitbits (coachs électroniques) et autres téléphones intelligents recueillent constamment des informations sur nous et notre environnement. Ces informations sont précieuses non seulement pour nous, mais aussi pour les gens qui veulent nous vendre des choses. Ils veillent à ce que les appareils connectés soient programmés de manière à ce qu’ils partagent volontiers de l’information…
Les atteintes à la sécurité et à la vie privée sont intégrées
Comme le Roomba, d’autres appareils intelligents peuvent être programmés pour partager nos informations privées avec les annonceurs publicitaires par le biais de canaux dissimulés. Dans un cas bien plus intime que le Roomba, un appareil de massage érotique contrôlable par smartphone, appelé WeVibe, recueillait des informations sur la fréquence, les paramètres et les heures d’utilisation. L’application WeVibe renvoyait ces données à son fabricant, qui a accepté de payer plusieurs millions de dollars dans le cadre d’un litige juridique lorsque des clients s’en sont aperçus et ont contesté cette atteinte à la vie privée.
Ces canaux dissimulés constituent également une grave faille de sécurité. Il fut un temps, le fabricant d’ordinateurs Lenovo, par exemple, vendait ses ordinateurs avec un programme préinstallé appelé Superfish. Le programme avait pour but de permettre à Lenovo — ou aux entreprises ayant payé — d’insérer secrètement des publicités ciblées dans les résultats de recherches web des utilisateurs. La façon dont Lenovo a procédé était carrément dangereuse : l’entreprise a modifié le trafic des navigateurs à l’insu de l’utilisateur, y compris les communications que les utilisateurs croyaient chiffrées, telles que des transactions financières via des connexions sécurisées à des banques ou des boutiques en ligne.
Le problème sous-jacent est celui de la propriété
L’une des principales raisons pour lesquelles nous ne contrôlons pas nos appareils est que les entreprises qui les fabriquent semblent penser que ces appareils leur appartiennent toujours et agissent clairement comme si c’était le cas, même après que nous les avons achetés. Une personne peut acheter une jolie boîte pleine d’électronique qui peut fonctionner comme un smartphone, selon les dires de l’entreprise, mais elle achète une licence limitée à l’utilisation du logiciel installé. Les entreprises déclarent qu’elles sont toujours propriétaires du logiciel et que, comme elles en sont propriétaires, elles peuvent le contrôler. C’est comme si un concessionnaire automobile vendait une voiture, mais revendiquait la propriété du moteur.
Ce genre de disposition anéantit le fondement du concept de propriété matérielle. John Deere a déjà annoncé aux agriculteurs qu’ils ne possèdent pas vraiment leurs tracteurs, mais qu’ils ont, en fait, uniquement le droit d’en utiliser le logiciel — ils ne peuvent donc pas réparer leur propre matériel agricole ni même le confier à un atelier de réparation indépendant. Les agriculteurs s’y opposent, mais il y a peut-être des personnes prêtes à l’accepter, lorsqu’il s’agit de smartphones, souvent achetés avec un plan de paiement échelonné et échangés à la première occasion.
Combien de temps faudra-t-il avant que nous nous rendions compte que ces entreprises essaient d’appliquer les mêmes règles à nos maisons intelligentes, aux téléviseurs intelligents dans nos salons et nos chambres à coucher, à nos toilettes intelligentes et à nos voitures connectées à Internet ?
Un retour à la féodalité ?
La question de savoir qui contrôle la propriété a une longue histoire. Dans le système féodal de l’Europe médiévale, le roi possédait presque tout, et l’accès à la propriété des autres dépendait de leurs relations avec le roi. Les paysans vivaient sur des terres concédées par le roi à un seigneur local, et les ouvriers ne possédaient même pas toujours les outils qu’ils utilisaient pour l’agriculture ou d’autres métiers comme la menuiserie et la forge.
Au fil des siècles, les économies occidentales et les systèmes juridiques ont évolué jusqu’à notre système commercial moderne : les individus et les entreprises privées achètent et vendent souvent eux-mêmes des biens de plein droit, possèdent des terres, des outils et autres objets. Mis à part quelques règles gouvernementales fondamentales comme la protection de l’environnement et la santé publique, la propriété n’est soumise à aucune condition.
Ce système signifie qu’une société automobile ne peut pas m’empêcher de peindre ma voiture d’une teinte rose pétard ou de faire changer l’huile dans le garage automobile de mon choix. Je peux même essayer de modifier ou réparer ma voiture moi-même. Il en va de même pour ma télévision, mon matériel agricole et mon réfrigérateur.
Pourtant, l’expansion de l’Internet des objets semble nous ramener à cet ancien modèle féodal où les gens ne possédaient pas les objets qu’ils utilisaient tous les jours. Dans cette version du XXIe siècle, les entreprises utilisent le droit de la propriété intellectuelle — destiné à protéger les idées — pour contrôler les objets physiques dont les utilisateurs croient être propriétaires.
Mainmise sur la propriété intellectuelle
Mon téléphone est un Samsung Galaxy. Google contrôle le système d’exploitation ainsi que les applications Google Apps qui permettent à un smartphone Android de fonctionner correctement. Google en octroie une licence à Samsung, qui fait sa propre modification de l’interface Android et me concède le droit d’utiliser mon propre téléphone — ou du moins c’est l’argument que Google et Samsung font valoir. Samsung conclut des accords avec de nombreux fournisseurs de logiciels qui veulent prendre mes données pour leur propre usage.
Mais ce modèle est déficient, à mon avis. C’est notre droit de pouvoir réparer nos propres biens. C’est notre droit de pouvoir chasser les annonceurs qui envahissent nos appareils. Nous devons pouvoir fermer les canaux d’information détournés pour les profits des annonceurs, pas simplement parce que nous n’aimons pas être espionnés, mais aussi parce que ces portes dérobées constituent des failles de sécurité, comme le montrent les histoires de Superfish et de l’aquarium piraté. Si nous n’avons pas le droit de contrôler nos propres biens, nous ne les possédons pas vraiment. Nous ne sommes que des paysans numériques, utilisant les objets que nous avons achetés et payés au gré des caprices de notre seigneur numérique.
Même si les choses ont l’air sombres en ce moment, il y a de l’espoir. Ces problèmes deviennent rapidement des cauchemars en matière de relations publiques pour les entreprises concernées. Et il y a un appui bipartite important en faveur de projets de loi sur le droit à la réparation qui restaurent certains droits de propriété pour les consommateurs.
Ces dernières années, des progrès ont été réalisés dans la reconquête de la propriété des mains de magnats en puissance du numérique. Ce qui importe, c’est que nous identifiions et refusions ce que ces entreprises essaient de faire, que nous achetions en conséquence, que nous exercions vigoureusement notre droit d’utiliser, de réparer et de modifier nos objets intelligents et que nous appuyions les efforts visant à renforcer ces droits. L’idée de propriété est encore puissante dans notre imaginaire culturel, et elle ne mourra pas facilement. Cela nous fournit une opportunité. J’espère que nous saurons la saisir.
Le chemin vers une informatique éthique
Le logiciel « open source » a gagné, tant mieux, c’est un préalable pour une informatique éthique, explique Daniel Pascot, qui a tout au long d’une carrière bien remplie associé enseignement et pratique de l’informatique, y compris en créant une entreprise.
Du côté de nos cousins d’Outre-Atlantique, on lui doit notamment d’avoir présidé aux destinées de l’association libriste FACIL (c’est un peu l’April du Québec) et milité activement pour la promotion de solutions libres jusqu’aux instances gouvernementales.
On peut se réjouir de l’ubiquité du logiciel libre mais les fameuses quatre libertés du logiciel libre (merci Mr Stallman) ne semblent en réalité concerner que les créateurs de logiciels. Les utilisateurs, peu réceptifs au potentiel ouvert par les licences libres, sont intéressés essentiellement par l’usage libre des logiciels et les services proposés par des entreprises intermédiaires. Hic jacet lupus… Quand ces services échappent à la portée des licences libres, comment garantir qu’ils sont éthiques ? La réflexion qu’entame Daniel Pascot à la lumière d’exemples concrets porte de façon très intéressante sur les conditions d’un contrat équilibré entre utilisateurs et fournisseurs de services. Les propositions de charte qu’il élabore ressemblent d’ailleurs plutôt à une liste des droits des utilisateurs et utilisatrices 😉
Chez Framasoft, nous trouvons que ce sont là des réflexions et propositions fort bien venues pour le mouvement de CHATONS qui justement vous proposent des services divers en s’engageant par une charte.
Comme toujours sur le Framablog, les commentaires sont ouverts…
Le logiciel « open source » a gagné, oui mais…
Photo Yann Doublet
Les « libristes »1 se rendent progressivement compte que bien des combats qu’ils ont livrés étaient une cause perdue d’avance car ils sous-estimaient les conséquences de la complexité des logiciels. Quels que soient les bienfaits des logiciels libres, les utiliser exige une compétence et un entretien continu qui ne sont pas envisageables pour la grande majorité des individus ou organisations2.
Richard Stallman a fait prendre conscience de la nécessité de contrôler les programmes pour garantir notre liberté. La dimension éthique était importante : il parlait du bon et du mauvais logiciel. L’importance de ce contrôle a été mise en évidence par Lawrence Lessig avec son « Code is law »3. La nature immatérielle et non rivale du logiciel faisait que les libristes le considéraient naturellement comme un bien commun. Il leur semblait évident qu’il devait être partagé. Comme on vivait alors dans un monde où les ordinateurs étaient autonomes, la licence GPL avec ses libertés offrait un socle satisfaisant sur lequel les libristes s’appuyaient.
J’ai depuis plus de 20 ans enseigné et milité pour le logiciel libre que j’utilise quotidiennement. Comme tout bon libriste convaincu, j’ai présenté les quatre libertés de la GPL, et je reconnais que je n’ai pas convaincu grand monde avec ce discours. Qu’il faille garder contrôle sur le logiciel, parfait ! Les gens comprennent, mais la solution GPL ne les concerne pas parce que ce n’est absolument pas dans leur intention d’installer, étudier, modifier ou distribuer du logiciel. Relisez les licences et vous conviendrez qu’elles sont rédigées du point de vue des producteurs de logiciels plus que des utilisateurs qui n’envisagent pas d’en produire eux-mêmes.
Mais un objet technique et complexe, c’est naturellement l’affaire des professionnels et de l’industrie. Pour eux, la morale ou l’éthique n’est pas une préoccupation première, ce sont des techniciens et des marchands qui font marcher l’économie dans leur intérêt. Par contre, la liberté du partage du code pour des raisons d’efficacité (qualité et coût) les concerne. Ils se sont alors débarrassés de la dimension éthique en créant le modèle open source4. Et ça a marché rondement au point que ce modèle a gagné la bataille du logiciel. Les cinq plus grandes entreprises au monde selon leurs capitalisations boursières, les GAFAM, reposent sur ce modèle. Microsoft n’est plus le démon privatif à abattre, mais est devenu un acteur du libre. Enlevez le code libre et plus de Web, plus de courrier électronique, plus de réseaux sociaux comme Facebook, plus de service Google ou Amazon, ou de téléphone Apple ou Android. Conclusion : le logiciel libre a gagné face au logiciel propriétaire, c’est une question de temps pour que la question ne se pose plus.
Oui, mais voilà, c’est du logiciel libre débarrassé de toute évidence de sa dimension éthique, ce qui fait que du point de vue de l’utilisateur qui dépend d’un prestataire, le logiciel libre n’apporte rien. En effet, les prestataires de services, comme les réseaux sociaux ou les plates-formes de diffusion, ne distribuent pas de logiciel, ils en utilisent et donc échappent tout à fait légalement aux contraintes éthiques associées aux licences libres. Ce qui importe aux utilisateurs ce ne sont pas les logiciels en tant qu’objets, mais le service qu’ils rendent qui, lui, n’est pas couvert par les licences de logiciel libre. Circonstance aggravante, la gratuité apparente de bien des services de logiciel anesthésie leurs utilisateurs face aux conséquences de leur perte de liberté et de l’appropriation de leurs données et comportements (méta données) souvent à leur insu5.
Pourtant, aujourd’hui, nous ne pouvons plus nous passer de logiciel, tout comme nous ne pouvons pas nous passer de manger. Le logiciel libre c’est un peu comme le « bio » : de plus en plus de personnes veulent manger bio, tout simplement parce que c’est bon pour soi (ne pas s’empoisonner), bon pour la planète (la préserver de certaines pollutions) ou aussi parce que cela permet d’évoluer vers une économie plus humaine à laquelle on aspire (économie de proximité). Le « bio » est récent, mais en pleine expansion, il y a de plus en plus de producteurs, de marchands, et nos gouvernements s’en préoccupent par des lois, des règlements, des certifications ou la fiscalité. Ainsi le « bio » ce n’est pas seulement un produit, mais un écosystème complexe qui repose sur des valeurs : si le bio s’était limité à des « écolos » pour auto-consommation, on n’en parlerait pas. Eh bien le logiciel c’est comme le bio, ce n’est pas seulement un produit mais aussi un écosystème complexe qui concerne chacun de nous et la société avec tous ses acteurs.
Dans l’écosystème logiciel, les éditeurs et les prestataires de service qui produisent et opèrent le logiciel, ont compris que le logiciel libre (au sens open source) est bon pour eux et s’en servent, car ils le contrôlent. Par contre il n’en va pas de même pour ceux qui ne contrôlent pas directement le logiciel. La licence du logiciel ne suffit pas à leur donner contrôle. Mais alors que faire pour s’assurer que le service rendu par le logiciel via un prestataire soit bon pour nous, les divers utilisateurs dans cet écosystème numérique complexe ?
Je vais ici commenter la dimension éthique de deux projets de nature informatique qui s’appuient sur du logiciel libre sur lesquels je travaille actuellement en tentant d’intégrer ma réflexion de militant, d’universitaire et de praticien. PIAFS concerne les individus et donc le respect de nos vies privées pour des données sensibles, celles de notre santé dans un contexte de partage limité, la famille. REA vise à garantir à une organisation le contrôle de son informatisation dans le cadre d’une relation contractuelle de nature coopérative.
Deux cas qui ont alimenté ma réflexion
PIAFS : Partage des Informations Avec la Famille en Santé
PIAFS est projet qui répond à un besoin non satisfait : un serveur privé pour partager des données de santé au sein d’une unité familiale à des fins d’entr’aide (http://piafs.org/). Cette idée, dans un premier temps, a débouché sur un projet de recherche universitaire pour en valider et préciser la nature. Pour cela il nous fallait un prototype.
Au-delà de la satisfaction d’un besoin réel, je cherchais en tant que libriste comment promouvoir le logiciel libre. Je constatais que mes proches n’étaient pas prêts à renoncer à leurs réseaux sociaux même si je leur en montrais les conséquences. Il fallait éviter une première grande difficulté : changer leurs habitudes. J’avais là une opportunité : mes proches, comme beaucoup de monde, n’avaient pas encore osé organiser leurs données de santé dans leur réseau social.
Si ce projet avait dès le départ une dimension éthique, il n’était pas question de confier ces données sensibles à un réseau social. J’étais dès le départ confronté à une dimension pratique au-delà de la disponibilité du logiciel. De plus, pour les utilisateurs de PIAFS, l’auto-hébergement n’est pas une solution envisageable. Il fallait recourir à un fournisseur car un tel service doit être assuré d’une manière responsable et pérenne. Même si l’on s’appuyait sur des coopératives de santé pour explorer le concept, il est rapidement apparu qu’il fallait recourir à un service professionnel classique dont il faut alors assumer les coûts6. Il fallait transposer les garanties apportées par le logiciel libre au fournisseur de service : l’idée de charte que l’on voyait émerger depuis quelques années semblait la bonne approche pour garantir une informatique éthique, et en même temps leur faire comprendre qu’ils devaient eux-mêmes assurer les coûts du service.
REA : Pour donner au client le contrôle de son informatisation
J’ai enseigné la conception des systèmes d’information dans l’université pendant près de 40 ans (à Aix-en-Provence puis à Québec), et eu l’occasion de travailler dans des dizaines de projets. J’ai eu connaissance de nombreux dérapages de coût ou de calendrier et j’ai étudié la plupart des méthodologies qui tentent d’y remédier. J’ai aussi appris qu’une des stratégies commerciales de l’industrie informatique (ils ne sont pas les seuls !) est la création de situations de rente pas toujours à l’avantage du client. Dans tout cela je n’ai pas rencontré grande préoccupation éthique.
J’ai eu, dès le début de ma carrière de professeur en systèmes d’information (1971), la chance d’assister, sinon participer, à la formalisation de la vision de Jean-Louis Le Moigne7 : un système d’information consiste à capturer, organiser et conserver puis distribuer et parfois traiter les informations créées par l’organisation. Cette vision s’opposait aux méthodologies naissantes de l’analyse structurée issues de la programmation structurée. Elle établissait que l’activité de programmation devait être précédée par une compréhension du fonctionnement de l’organisation à partir de ses processus. L’approche qui consiste à choisir une « solution informatique » sans vraiment repenser le problème est encore largement dominante. J’ai ainsi été conduit à développer, enseigner et pratiquer une approche dite à partir des données qui s’appuie sur la réalisation précoce de prototypes fonctionnels afin de limiter les dérapages coûteux (je l’appelle maintenant REA pour Référentiel d’Entreprise Actif, le code de REA est bien sûr libre).
Mon but est, dans ma perspective libriste, de redonner le contrôle au client dans la relation client-fournisseur de services d’intégration. Si ce contrôle leur échappe trop souvent du fait de leur incompétence technique, il n’en reste pas moins que ce sont eux qui subissent les conséquences des systèmes informatiques « mal foutus ». Là encore le logiciel libre ne suffit pas à garantir le respect du client et le besoin d’une charte pour une informatique éthique s’impose8 .
Vers une charte de l’informatique libre, c’est-à-dire bonne pour l’écosystème numérique
Dans les deux cas, si l’on a les ressources et la compétence pour se débrouiller seul, les licences libres comme la GPL ou une licence Creative Commons pour la méthodologie garantissent une informatique éthique (respect de l’utilisateur, contribution à un bien commun). S’il faut recourir à un hébergeur ou un intégrateur, les garanties dépendent de l’entente contractuelle entre le client-utilisateur et le fournisseur.
Il y a une différence fondamentale entre le logiciel et le service. Le logiciel est non rival, il ne s’épuise pas à l’usage, car il peut être reproduit sans perte pour l’original, alors que le service rendu est à consommation unique. Le logiciel relève de l’abondance alors que le service relève de la rareté qui est le fondement de l’économie qui nous domine, c’est la rareté qui fait le prix. Le logiciel peut être mis en commun et partagé alors que le service ne le peut pas. L’économie d’échelle n’enlève pas le caractère rival du service. Et c’est là que la réalité nous rattrape : la mise en commun du logiciel est bonne pour nous tous, mais cela n’a pas de sens pour le service car aucun fournisseur ne rendra ce service gratuitement hormis le pur bénévolat.
Des propositions balisant un comportement éthique existent, en voici quelques exemples:
dans Le Manifeste pour le développement Agile de logiciels, des informaticiens ont proposé une démarche dite agile qui repose sur 4 valeurs et 12 principes. Sans être explicitement une charte éthique, la démarche est clairement définie dans l’optique du respect du client. Ce manifeste est utile dans le cas REA ;
la charte du collectif du mouvement CHATONS concerne les individus, elle est pensée dans un contexte d’économie sociale et solidaire, elle est inspirante pour le cas PIAFS ;
la charte de Framasoft définit un internet éthique, elle est inspirante pour le cas PIAFS mais aussi pour la définition d’un cadre global;
dernièrement sous forme de lettre ouverte, un collectif issu du Techfestival de Copenhague propose une pratique éthique, utile pour les deux cas et qui permet de réfléchir au cadre global.
Les libristes, mais dieu merci ils ne sont pas les seuls, ont une bonne idée des valeurs qui président à une informatique éthique, bonne pour eux, à laquelle ils aspirent lorsqu’ils utilisent les services d’un fournisseur. Les exigences éthiques ne sont cependant pas les mêmes dans les deux cas car l’un concerne un service qui n’inclut pas de développement informatique spécifique et l’autre implique une activité de développement significative (dans le tableau ci-dessous seuls des critères concernant l’éthique sont proposés):
Critères pour le client
Dans le cas de PIAFS
Dans le cas d’un projet REA
Respect de leur propriété
Les données qu’ils produisent leur appartiennent, ce n’est pas négociable
Tout document produit (analyse, …) est propriété du client
Respect de leur identité
Essentiel
Le client doit contrôler la feuille de route, ce sont ses besoins que l’on doit satisfaire par ceux du fournisseur
Respect de leur indépendance vis à vis du fournisseur
Important, préside au choix des logiciels et des formats
Critique : mais difficile à satisfaire.
Proximité du service : favoriser l’économie locale et protection contre les monopoles
Important
Important
Pérennité du service
Important, mais peut être tempéré par la facilité du changement
Essentiel : le changement est difficile et coûteux, mais la « prise en otage » est pire
Payer le juste prix
Important
Important
Partage équitable des risques
Risque faible
Essentiel car le risque est élevé
Mise en réseau
Essentiel : la connexion « sociale » est impérative mais dans le respect des autres valeurs
Plus aucune organisation vit en autarcie
Contribution (concerne le fournisseur)
Non discutable, obligatoire
Important mais aménageable
Entente sur le logiciel
Le client, individu ou organisation, doit avoir l’assurance que les logiciels utilisés par le fournisseur de services font bien et seulement ce qu’ils doivent faire. Comme il n’a pas la connaissance requise pour cette expertise, il doit faire confiance au fournisseur. Or, parce que celui-ci n’offre pas toute la garantie requise (volonté et capacité de sa part), il faut, dans cette situation, recourir à un tiers de confiance. Cette expertise externe par un tiers de confiance est très problématique. Il faut d’une part que le fournisseur donne accès aux logiciels et d’autre part trouver un expert externe qui accepte d’étudier les logiciels, autrement dit résoudre la quadrature du cercle !
Le logiciel libre permet de la résoudre. Il est accessible puisqu’il est public, il est produit par une communauté qui a les qualités requises pour jouer ce rôle de tiers de confiance. Ainsi, pour une informatique éthique :
tout logiciel utilisé par le fournisseur doit être public, couvert par une licence libre, ce qui le conduit à ne pas redévelopper un code existant ou le moins possible,
s’il est amené à produire du nouveau code,
le fournisseur doit le rendre libre. C’est à l’avantage de la société mais aussi du client dans un contexte de partage et de protection contre les situations de rente qui le tiennent en otage,
ou du moins le rendre accessible au client,
garantir que seul le code montré est utilisé,
utiliser des formats de données et documents libres.
L’éthique est complexe, il est difficile sinon impossible d’anticiper tous les cas. L’exigence de logiciel libre peut être adaptée à des situations particulières, par exemple si le prestataire est engagé pour un logiciel que le client ne désire pas partager il en prend alors la responsabilité, ou si la nécessité de poursuivre l’utilisation de logiciels non libres est non contournable temporairement.
Entente sur le bien ou service
Le critère du coût est propre au service. Dans une approche éthique le juste coût n’est pas la résultante du jeu de l’offre et de la demande, ni d’un jeu de négociation basé sur des secrets, et encore moins le résultat d’une rente de situation. Il s’agit pour le fournisseur de couvrir ses coûts et de rentabiliser son investissement (matériel, formation…). Une approche éthique impose de la transparence, le client :
doit savoir ce qu’il paye,
doit avoir la garantie que le contrat couvre tous les frais pour l’ensemble du service (pas de surprise à venir),
doit être capable d’estimer la valeur de ce qu’il paye,
doit connaître les coûts de retrait du service et en estimer les conséquences.
Le partage équitable du risque concerne essentiellement les projets d’informatisation avec un intégrateur. Il est rare que l’on puisse estimer correctement l’ampleur d’un projet avant de l’avoir au moins partiellement réalisé. Une part du risque provient de l’organisation et de son environnement, une autre part du risque provient des capacités du fournisseur et de ses outils. Ceci a un impact sur le découpage du projet, chaque étape permet d’estimer les suivantes :
tout travail réalisé par le fournisseur contributif au projet :
doit être payé,
appartient au client,
doit pouvoir être utilisé indépendamment du fournisseur.
le travail dont le volume est dépendant du client est facturé au temps,
le travail sous le contrôle du fournisseur doit si possible être facturé sur une base forfaitaire,
le client est maître de la feuille de route,
tout travail entamé par le fournisseur doit être compris et accepté par le client,
la relation entre le client et le fournisseur est de nature collaborative, le client participe au projet qui évolue au cours de la réalisation à la différence d’une relation contractuelle dans laquelle le client commande puis le fournisseur livre ce qui est commandé.
Conclusion : l’informatique éthique est possible
Pour tous les utilisateurs de l’informatique, c’est à dire pratiquement tout le monde et toutes les organisations de notre société numérique, il est aussi difficile de nier l’intérêt d’une informatique éthique que de rejeter le « bio », mais encore faut-il en être conscient. Le débat au sein des producteurs de logiciels reste difficile à comprendre. Ce qui est bon pour un libriste c’est un logiciel qui avant tout le respecte, alors que pour les autres informaticiens, c’est à dire la grande majorité, c’est un logiciel qui ne bogue pas. Fait aggravant : la vérité des coûts nous est cachée. Cependant au-delà de cette différence philosophique, l’intérêt du logiciel partagé est tel qu’un immense patrimoine de logiciel libre ou open source est disponible. Ce patrimoine est le socle sur lequel une informatique éthique est possible. Les deux cas présentés nous montent que les conditions existent dès maintenant.
Une informatique éthique est possible, mais elle ne sera que si nous l’exigeons. Les géants du Net sont de véritables états souverains devant lesquels même nos états baissent pavillon. La route est longue, chaotique et pleine de surprises, comme elle l’a été depuis la naissance de l’ordinateur, mais un fait est acquis, elle doit reposer sur le logiciel libre.
Le chemin se fait en marchant, comme l’écrivait le poète Antonio Machado, et c’est à nous libristes de nous donner la main et de la tendre aux autres. Ce ne sera pas facile car il faudra mettre la main à la poche et la bataille est politique. Il nous faut exiger, inspirés par le mouvement « bio », un label informatique éthique et pourquoi pas un forum mondial de l’écosystème numérique. La piste est tracée (à l’instar de la Quadrature du Net), à nous de l’emprunter.
Notes
J’ai utilisé ce mot de libriste pour rendre compte de la dimension militante et à certains égards repliée sur elle-même, qu’on leur reproche souvent à raison.↩
Dans un article paru en 2000, Lawrence Lessig -auquel on doit les licences Creative Commons- a clairement mis en lumière que l’usage d’internet (et donc des logiciels) nous contraint, tout comme nous sommes contraint par les lois. Il nous y a alerté sur les conséquences relatives à notre vie privée. Voir la traduction française sur Framablog « Le code fait loi – De la liberté dans le cyberespace » (publié le 22/05/2010),↩
Dans l’optique open source, un bon logiciel est un logiciel qui n’a pas de bogue. Dans l’optique logiciel libre, un bon logiciel est un logiciel éthique qui respecte son utilisateur et contribue au patrimoine commun. Dans les deux cas il est question d’accès au code source mais pour des raisons différentes, ce qui au plan des licences peut sembler des nuances : « Né en 1998 d’une scission de la communauté du logiciel libre (communauté d’utilisateurs et de développeurs) afin de conduire une politique jugée plus adaptée aux réalités économiques et techniques, le mouvement open source défend la liberté d’accéder aux sources des programmes qu’ils utilisent, afin d’aboutir à une économie du logiciel dépendant de la seule vente de prestations et non plus de celle de licences d’utilisation ». Voir la page Wikipédia, « Open Source Initiative ».↩
La question de recourir à une organisation de l’économie sociale et solidaire s’est posée et ce n’est pas exclu.Cela n’a pas été retenu pour des raisons pratiques et aussi parce que la démarche visait à promouvoir une informatique éthique de la part des fournisseurs traditionnels locaux.↩
Avant d’être connu comme un constructiviste Jean-Louis Le Moigne, alors professeur à l’IAE d’Aix-en-Provence, créait un enseignement de systèmes d’information organisationnels et lançait avec Huber Tardieu la recherche qui a conduit à la méthode Merise à laquelle j’ai participé car j’étais alors assistant dans sa petite équipe universitaire et il a été mon directeur de doctorat.↩
Caliopen, la messagerie libre sur la rampe de lancement
Le projet Caliopen, lancé il y a trois ans, est un projet ambitieux. Alors qu’il est déjà complexe de créer un nouveau logiciel de messagerie, il s’agit de proposer un agrégateur de correspondance qui permette à chacun d’ajuster son niveau de confidentialité.
Ce logiciel libre mûrement réfléchi est tout à fait en phase avec ce que Framasoft s’efforce de promouvoir à chaque fois que des libristes donnent aux utilisateurs et utilisatrices plus d’autonomie et de maîtrise, plus de sécurité et de confidentialité.
Après une nécessaire période d’élaboration, le projet Caliopen invite tout le monde à tester la version alpha et à faire remonter les observations et suggestions. La première version grand public ce sera pour dans un an environ.
Vous êtes curieux de savoir ce que ça donne ? Nous l’étions aussi, et nous avons demandé à Laurent Chemla, qui bidouillait déjà dans l’Internet alors que vous n’étiez même pas né⋅e, de nous expliquer tout ça, puisqu’il est le père tutélaire du projet Caliopen, un projet que nous devons tous soutenir et auquel nous pouvons contribuer.
Bonjour, pourrais-tu te présenter brièvement ?
J’ai 53 ans, dont 35 passés dans les mondes de l’informatique et des réseaux. Presque une éternité dans ce milieu – en tous cas le temps d’y vivre plusieurs vies (« pirate », programmeur, hacktiviste, entrepreneur…). Mais ces temps-ci je suis surtout le porteur du projet Caliopen, même si je conserve une petite activité au sein du CA de la Quadrature du Net. Et je fais des macarons.
Le projet Caliopen arrive ce mois-ci au stade de la version alpha, mais comment ça a commencé ?
Jérémie Zimmermann est venu me sortir de ma retraite nîmoise en me poussant à relancer un très ancien projet de messagerie après les révélations de Snowden. Ça faisait déjà un petit moment que je me demandais si je pouvais encore être utile à la communauté autrement qu’en publiant quelques billets de temps en temps, alors j’ai lancé l’idée en public, pour voir, et il y a eu un tel retour que je n’ai pas pu faire autrement que d’y aller, malgré ma flemme congénitale.
Quand tu as lancé le projet publiquement (sur une liste de diffusion il me semble) quelle était la feuille de route, ou plutôt la « bible » des spécifications que tu souhaitais voir apparaître dans Caliopen ?
Très vite on a vu deux orientations se dessiner : la première, très technique, allait vers une vision maximaliste de la sécurité (réinventer SMTP pour protéger les métadonnées, garantir l’anonymat, passer par du P2P, ce genre de choses), tandis que la seconde visait à améliorer la confidentialité des échanges sans tout réinventer. Ça me semblait plus réaliste – parce que compatible avec les besoins du grand public – et c’est la direction que j’ai choisi de suivre au risque de fâcher certains contributeurs.
J’ai alors essayé de lister toutes les fonctionnalités (aujourd’hui on dirait les « User Stories ») qui sont apparues dans les échanges sur cette liste, puis de les synthétiser, et c’est avec ça que je suis allé voir Stephan Ramoin, chez Gandi, pour lui demander une aide qu’il a aussitôt accepté de donner. Le projet a ensuite évolué au rythme des échanges que j’ai pu avoir avec les techos de Gandi, puis de façon plus approfondie avec Thomas Laurent pendant la longue étape durant laquelle nous avons imaginé le design de Caliopen. C’est seulement là, après avoir défini le « pourquoi » et le « quoi » qu’on a pu vraiment commencer à réfléchir au « comment » et à chercher du monde pour le réaliser.
La question qui fâche : quand on lit articles et interviews sur Caliopen, on a l’impression que le concept est encore super flou. C’est quoi l’elevator pitch pour vendre le MVP de la start-up aux business angels des internets digitaux ? (en français : tu dis quoi pour convaincre de nouveaux partenaires financiers ?)
Ça fait bien 3 ans que le concept de base n’a pas bougé : un agrégateur de correspondances qui réunit tous nos échanges privés (emails, message Twitter ou Facebook, messageries instantanées…), sous forme de conversations, définies par ceux avec qui on discute plutôt que par le protocole utilisé pour le faire. Voilà pour ton pitch.
Ce qui est vrai c’est qu’en fonction du public auquel on s’adresse on ne présente pas forcément le même angle. Le document qui a été soumis à BPI France pour obtenir le financement actuel fait 23 pages, très denses. Il aborde les aspects techniques, financiers, l’état du marché, la raison d’être de Caliopen, ses objectifs sociétaux, ses innovations, son design, les différents modèles économiques qui peuvent lui être appliqués… ce n’est pas quelque chose qu’on peut développer en un article ou une interview unique.
Si j’aborde Caliopen sous l’angle de la vie privée, alors j’explique par exemple le rôle des indices de confidentialité, la façon dont le simple fait d’afficher le niveau de confidentialité d’un message va influencer l’utilisateur dans ses pratiques: on n’écrit pas la même chose sur une carte postale que dans une lettre sous enveloppe. Rien que sur ce sujet, on vient de faire une conférence entière (à Paris Web et à BlendWebMix) sans aborder aucun des autres aspects du projet.
Si je l’aborde sous l’angle technique, alors je vais peut-être parler d’intégration « verticale ». Du fait qu’on ne peut pas se contenter d’un nouveau Webmail, ou d’un nouveau protocole, si on veut tenir compte de tous les aspects qui font qu’un échange est plus ou moins secret. Ce qui fait de Caliopen un ensemble de différentes briques plutôt qu’une unique porte ou fenêtre. Ou alors je vais parler de la question du chiffrement, de la diffusion des clés publiques, de TOFU et du RFC 7929…
Mais on peut aussi débattre du public visé, de design, d’économie du Web, de décentralisation… tous ces angles sont pertinents, et chacun peut permettre de présenter Caliopen avec plus ou moins de détails.
Caliopen est un projet complexe, fondé sur un objectif (la lutte contre la surveillance de masse) et basé sur un moyen (proposer un service utile à tous), qui souhaite changer les habitudes des gens en les amenant à prendre réellement conscience du niveau d’exposition de leur vie privée. Il faut plus de talent que je n’en ai pour le décrire en quelques mots.
Il reste un intérêt pour les mails ? On a l’impression que tout passe par les webmails ou encore dans des applis de communication sur mobile, non ?
Même si je ne crois pas à la disparition de l’email, c’est justement parce qu’on a fait le constat qu’aujourd’hui la correspondance numérique passe par de très nombreux services qu’on a imaginé Caliopen comme un agrégateur de tous ces échanges.
C’est un outil qui te permet de lire et d’écrire à tes contacts sans avoir à te préoccuper du service, ou de l’application, où la conversation a commencé. Tu peux commencer un dialogue avec quelqu’un par message privé sur Twitter, la poursuivre par email, puis par messagerie instantanée… ça reste une conversation: un échange privé entre deux humains, qui peuvent aborder différents sujets, partager différents contenus. Et quand tu vas vouloir chercher l’information que l’autre t’a donné l’année passée, tu vas faire comment ?
C’est à ça que Caliopen veut répondre. Pour parler moderne, c’est l’User Story centrale du projet.
C’est quoi exactement cette histoire de niveaux de confidentialité ? Quel est son but ?
Il faut revenir à l’objectif principal du projet : lutter contre la surveillance de masse que les révélations d’Edward Snowden ont démontrée.
Pour participer à cette lutte, Caliopen vise à convaincre un maximum d’utilisateurs de la valeur de leur vie privée. Et pour ça, il faut d’abord leur montrer, de manière évidente, que leurs conversations sont très majoritairement espionnables, sinon espionnées. Notre pari, c’est que quand on voit le risque d’interception, on réagit autrement que lorsqu’on est seulement informé de son existence. C’est humain : regarde l’exemple de la carte postale que je te donne plus haut.
D’où l’idée d’associer aux messages (mais aussi aux contacts, aux terminaux, et même à l’utilisateur lui-même) un niveau de confidentialité. Représenté par une icône, des couleurs, des chiffres, c’est une question de design, mais ce qui est important c’est qu’en voyant le niveau de risque, l’utilisateur ne va plus pouvoir faire semblant de l’ignorer et qu’il va accepter de changer – au moins un peu – ses pratiques et ses habitudes pour voir ce niveau augmenter.
Bien sûr, il faudra l’accompagner. Lui proposer des solutions (techniques, comportementales, contextuelles) pour améliorer son « score ». Sans le culpabiliser (ce n’est pas la bonne manière de faire) mais en le récompensant – par une meilleure note, de nouvelles fonctionnalités, des options gratuites si le service est payant… bref par une ludification de l’expérience utilisateur. C’est notre piste en tous cas.
Et c’est en augmentant le niveau global de confidentialité des échanges qu’on veut rendre plus difficile (donc plus chère) la surveillance de tous, au point de pousser les états – et pourquoi pas les GAFAM – à changer de pratiques, eux aussi.
Financièrement, comment vit le projet Caliopen ? C’était une difficulté qui a retardé l’avancement ?
Sans doute un peu, mais je voudrais quand même dire que, même si je suis bien conscient de l’impression de lenteur que peut donner le projet, il faut se rendre compte qu’on parle d’un outil complexe, qui a démarré de zéro, avec aucun moyen, et qui s’attaque à un problème dont les racines datent de plusieurs dizaines d’années. Si c’était facile et rapide à résoudre, ça se saurait.
Dès l’instant où nous avons pris conscience qu’on n’allait pas pouvoir continuer sur le modèle du bénévolat, habituel au milieu du logiciel libre, nous avons réagi assez vite : Gandi a décidé d’embaucher à plein temps un développeur front end, sur ses fonds propres. Puis nous avons répondu à un appel à projet de BPI France qui tombait à pic et auquel Caliopen était bien adapté. Nous avons défendu notre dossier, devant un comité de sélection puis devant un panel d’experts, et nous avons obtenu de quoi financer deux ans de développement, avec une équipe dédiée et des partenaires qui nous assurent de disposer de compétences techniques rares. Et tout ça est documenté sur notre blog, depuis le début (tout est public depuis le début, d’ailleurs, même si tous les documents ne sont pas toujours faciles à retrouver, même pour nous).
Et finalement c’est qui les partenaires ?
Gandi reste le partenaire principal, auquel se sont joints Qwant et l’UPMC (avec des rôles moins larges mais tout aussi fondamentaux).
Quel est le modèle économique ? Les développeurs (ou développeuses, y’en a au fait dans l’équipe ?) sont rémunérés autrement qu’en macarons ? Combien faudra-t-il payer pour ouvrir un compte ?
Je ne suis pas sûr qu’on puisse parler de « modèle économique » pour un logiciel libre : après tout chacun pourra en faire ce qu’il voudra et lui imaginer tel ou tel modèle (économique ou non d’ailleurs).
Une fois qu’on a dit ça, on peut quand même dire qu’il ne serait pas cohérent de baser des services Caliopen sur l’exploitation des données personnelles des utilisateurs, et donc que le modèle « gratuité contre données » n’est pas adapté. Nous imaginons plutôt des services ouverts au public de type freemium, d’autres fournis par des entreprises pour leurs salariés, ou par des associations pour leurs membres. On peut aussi supposer que se créeront des services pour adapter Caliopen à des situations particulières, ou encore qu’il deviendra un outil fourni en Saas, ou vendu sous forme de package associé, par exemple, à la vente d’un nom de domaine.
Bref : les modèles économiques ce n’est pas ce qui manque le plus.
L’équipe actuelle est salariée, elle comporte des développeuses, et tu peux voir nos trombinettes sur https://www.caliopen.org
L’équipe de Caliopen
Trouver des développeurs ou développeuses n’est jamais une mince affaire dans le petit monde de l’open source, comment ça s’est passé pour Caliopen ?
Il faut bien comprendre que – pour le moment – Caliopen n’a pas d’existence juridique propre. Les gens qui bossent sur le projet sont des employés de Gandi (et bientôt de Qwant et de l’UPMC) qui ont soit choisi de consacrer une partie de leur temps de travail à Caliopen (ce que Gandi a rendu possible) soit été embauchés spécifiquement pour le projet. Et parfois nous avons des bénévoles qui nous rejoignent pour un bout de chemin 🙂
Le projet est encore franco-français. Tu t’en félicites (cocorico) ou ça t’angoisse ?
J’ai bien des sujets d’angoisse, mais pas celui-là. C’est un problème, c’est vrai, et nous essayons de le résoudre en allant, par exemple, faire des conférences à l’étranger (l’an dernier au FOSDEM, et cette année au 34C3 si notre soumission est acceptée). Et le site est totalement trilingue (français, anglais et italien) grâce au travail (bénévole) de Daniele Pitrolo.
D’un autre côté il faut quand même reconnaître que bosser au quotidien dans sa langue maternelle est un vrai confort dont il n’est pas facile de se passer. Même si on est tous conscients, je crois, qu’il faudra bien passer à l’anglais quand l’audience du projet deviendra un peu plus internationale, et nous comptons un peu sur les premières versions publiques pour que ça se produise.
Et au fait, c’est codé en quoi, Caliopen ? Du JavaScript surtout, d’après ce qu’on voit sur GitHub, mais nous supposons qu’il y a pas mal de technos assez pointues pour un tel projet ?
Sur GitHub, le code de Caliopen est dans un mono-repository, il n’y a donc pas de paquet (ou dépôt) spécifique au front ou au back. Le client est développé en JavaScript avec la librarie ReactJS. Le backend (l’API ReST, les workers …) sont développés en python et en Go. On n’a pas le détail mais ce doit être autour de 50% JS+css, 25% python, 25% Go. L’architecture est basée sur Cassandra et ElasticSearch.
Ce n’est pas que l’on utilise des technos pointues, mais plutôt qu’ on évite autant que possible la dette technique en intégrant le plus rapidement possible les évolutions des langages et des librairies que l’on utilise.
Donc il faut vraiment un haut niveau de compétences pour contribuer ?
Difficile à dire. Si on s’arrête sur l’aspect développement pur, les technos employées sont assez grand public, et si on a suivi un cursus standard on va facilement retrouver ses habitudes (cf. https://github.com/kamranahmedse/developer-roadmap).
Effectivement quelqu’un qui n’a pas l’habitude de développer sur ces outils (docker, Go, webpack, ES6+ …) risque d’être un peu perdu au début. Mais on est très souvent disponibles sur IRC pour répondre directement aux questions.
Néanmoins nous avons de « simples » contributions qui ne nécessitent pas de connaître les patrons de conception par cœur ou de devoir monter un cluster; par exemple proposer des corrections orthographiques, de nouvelles traductions, décrire des erreurs JavaScript dans des issues sur github, modifier un bout de css…
Qu’est-ce qui différencie le projet Caliopen d’un projet comme Protonmail ?
Protonmail est un Gmail-like orienté vers la sécurité. Caliopen est un agrégateur de correspondance privée (ce qui n’est rien-like) orienté vers l’amélioration des pratiques du grand public via l’expérience utilisateur. Protonmail est centralisé, Caliopen a prévu tout un (futur) écosystème exclusivement destiné à garantir la décentralisation des échanges. Et puis Caliopen est un logiciel libre, pas Protonmail.
Mais au-delà de ces différences techniques et philosophiques, ce sont surtout deux visions différentes, et peut-être complémentaires, de la lutte contre la surveillance de masse: Protonmail s’attaque à la protection de ceux qui sont prêts à changer leurs habitudes (et leur adresse email) parce qu’ils sont déjà convaincus qu’il faut faire certains efforts pour leur vie privée. Caliopen veut changer les habitudes de tous les autres, en leur proposant un service différent (mais utile) qui va les sensibiliser à la question. Parce qu’il faut bien se rendre compte que, malgré son succès formidable, aujourd’hui le nombre d’utilisateurs de Protonmail ne représente qu’à peine un millième du nombre d’utilisateurs de Gmail, et que quand les premiers échangent avec les seconds ils ne sont pas mieux protégés que M. Michu.
Maintenant, si tu veux bien imaginer que Caliopen est aussi un succès (on a le droit de rêver) et qu’il se crée un jour disons une dizaine de milliers de services basés sur noooootre proooojet, chacun ne gérant qu’un petit dixième du nombre d’utilisateurs de Protonmail… Eh ben sauf erreur on équilibre le nombre d’utilisateurs de Gmail et – si on a raison de croire que l’affichage des indices de confidentialité va produire un effet – on a significativement augmenté le niveau global de confidentialité.
Et peut-être même assez pour que la surveillance de masse devienne hors de prix.
Est-ce que dans la future version de Caliopen les messages seront chiffrés de bout en bout ?
À chaque fois qu’un utilisateur de Caliopen va vouloir écrire à un de ses contacts, c’est le protocole le plus sécurisé qui sera choisi par défaut pour transporter son message. Prenons un exemple et imaginons que tu m’ajoutes à tes contacts dans Caliopen : tu vas renseigner mon adresse email, mon compte Twitter, mon compte Mastodon, mon Keybase… plus tu ajouteras de moyens de contact plus Caliopen aura de choix pour m’envoyer ton message. Et il choisira le plus sécurisé par défaut (mais tu pourras décider de ne pas suivre son choix).
Plus tes messages auront pu être sécurisés, plus hauts seront leurs indices de confidentialité affichés. Et plus les indices de confidentialité de tes échanges seront hauts, plus haut sera ton propre indice global (ce qui devrait te motiver à mieux renseigner ma fiche contact afin d’y ajouter l’adresse de mon email hébergé sur un service Caliopen, parce qu’alors le protocole choisi sera le protocole intra-caliopen qui aura un très fort indice de confidentialité).
Mais l’utilisateur moyen n’aura sans doute même pas conscience de tout ça. Simplement le système fera en sorte de ne pas envoyer un message en clair s’il dispose d’un moyen plus sûr de le faire pour tel ou tel contact.
Est-ce qu’on pourra (avec un minimum de compétences, par exemple pour des CHATONS) installer Caliopen sur un serveur et proposer à des utilisateurs et utilisatrices une messagerie à la fois sécurisée et respectueuse ?
C’est fondamental, et c’est un des enjeux de Caliopen. Souvent quand je parle devant un public technique je pose la question : « combien de temps mettez-vous à installer un site Web en partant de zéro, et combien de temps pour une messagerie complète ? ». Et les réponses aujourd’hui sont bien sûr diamétralement opposées à ce qu’elle auraient été 15 ans plus tôt, parce qu’on a énormément travaillé sur la facilité d’installation d’un site, depuis des années, alors qu’on a totalement négligé la messagerie.
Si on veut que Caliopen soit massivement adopté, et c’est notre objectif, alors il faudra qu’il soit – relativement – facile à installer. Au moins assez facile pour qu’une entreprise, une administration, une association… fasse le choix de l’installer plutôt que de déléguer à Google la gestion du courrier de ses membres. Il faudra aussi qu’il soit facilement administrable, et facile à mettre à jour. Et tout ceci a été anticipé, et analysé, durant tout ce temps où tu crois qu’on n’a pas été assez vite !
On te laisse le dernier mot comme il est de coutume dans nos interviews pour le blog…
À lire tes questions j’ai conscience qu’on a encore beaucoup d’efforts à faire en termes de communication. Heureusement pour nous, Julien Dubedout nous a rejoints récemment, et je suis sûr qu’il va beaucoup améliorer tout ça. 🙂
