Voici l’introduction du livre Des routes et des ponts de Nadia Eghbal (si vous avez raté le début…) que le groupe Framalang vous traduit au fil des semaines.

Dans cette partie, après avoir exposé la pression croissante de la demande de maintenance, elle retrace un épisode tout à fait emblématique, celui d’Heartbleed, quand il y a quelques années le monde de l’informatique prenait conscience qu’un protocole sensible et universel de sécurité n’était maintenu que par une poignée de développeurs sous-payés.

Vous souhaitez participer à la traduction hebdomadaire ? Rejoignez Framalang ou rendez-vous sur un pad dont l’adresse sera donnée sur Framasphère chaque mardi à 19h… mais si vous passez après vous êtes les bienvenu.e.s aussi !

Introduction

Traduction Framalang : Piup, xi, jums, goofy, Ced, mika, Luc, Laure, Lumibd, goofy, alienspoon, Julien / Sphinx

Tout, dans notre société moderne, des hôpitaux à la bourse en passant par les journaux et les réseaux sociaux, fonctionne grâce à des logiciels. Mais à y regarder de plus près, vous verrez que les fondations de cette infrastructure logicielle menacent de céder sous la demande. Aujourd’hui, presque tous les logiciels sont tributaires de code dit open source : public et gratuit, ce code est créé et maintenu par des communautés de développeurs ou disposant d’autres compétences. Comme les routes ou les ponts que tout le monde peut emprunter à pied ou dans un véhicule, le code open source peut être repris et utilisé par n’importe qui, entreprise ou particulier, pour créer des logiciels. Ce code constitue l’infrastructure numérique de la société d’aujourd’hui, et tout comme l’infrastructure matérielle, elle nécessite une maintenance et un entretien réguliers. Aux États-Unis par exemple, plus de la moitié des dépenses de l’état pour les réseaux routiers et ceux de distribution d’eau est consacrée à leur seule maintenance.

Mais les ressources financières nécessaires pour soutenir cette infrastructure numérique sont bien plus difficiles à obtenir. La maintenance de code open source était relativement abordable à ses débuts, mais de nos jours les financements ne viennent en général que d’entreprises de logiciels, sous forme de mécénat direct ou indirect. Dans la foulée de la révolution de l’ordinateur personnel, au début des années 1980, la plupart des logiciels du commerce étaient propriétaires, et non partagés. Les outils logiciels étaient conçus et utilisés en interne dans chaque entreprise, qui vendait aux clients une licence d’utilisation de ses produits. Beaucoup d’entreprises trouvaient que l’open source était un domaine émergent trop peu fiable pour un usage commercial. Selon elles, les logiciels devaient être vendus, pas donnés gratuitement.

En fait, partager du code s’est révélé plus facile, plus économique et plus efficace que d’écrire du code propriétaire, et de nos jours tout le monde utilise du code open source : les entreprises du Fortune 500, le gouvernement, les grandes entreprises du logiciel, les startups… Cependant, cette demande supplémentaire a augmenté la charge de travail de ceux qui produisent et entretiennent cette infrastructure partagée, mais comme ces communautés sont assez discrètes, le reste du monde a mis longtemps à s’en rendre compte. Parmi nous, beaucoup considèrent qu’ouvrir un logiciel est aussi normal que pousser un bouton pour allumer la lumière, mais nous ne pensons pas au capital humain qui a rendu cela possible.

Face à cette demande sans précédent, si nous ne soutenons pas notre infrastructure numérique les conséquences seront nombreuses. Du côté des risques, il y a les failles de sécurité et les interruptions de service causées par l’impossibilité pour les mainteneurs de fournir une assistance suffisante. Du côté des possibilités, les améliorations de ces outils logiciels sont nécessaires pour accompagner la renaissance actuelle des startups, qui dépendent étroitement de l’infrastructure numérique. De plus, le travail effectué dans l’open source est un atout dans le portfolio des développeurs et facilite leur recrutement, mais ce réservoir de talents est beaucoup moins diversifié que celui de l’industrie informatique dans son ensemble. Une augmentation du nombre de contributeurs serait donc profitable au domaine des technologies de l’information au sens large.

Aucune entreprise ou organisation n’a de raison de s’attaquer seule à ce problème, car le code open source est un bien public. C’est pourquoi nous devons réussir à travailler ensemble pour entretenir notre infrastructure numérique. Il existe par exemple la Core Infrastructure Initiative (CII) de la fondation Linux et le programme Open Source Support de Mozilla, ainsi que des initiatives de nombre d’entreprises de logiciel à différents niveaux.
L’entretien de notre infrastructure numérique est une idée nouvelle pour beaucoup, et les défis que cela pose ne sont pas bien cernés. De plus, l’initiative de cette infrastructure est distribuée entre beaucoup de personnes et d’organisations, ce qui met à mal les modèles classiques de gouvernance. Beaucoup de ces projets qui contribuent à l’infrastructure n’ont même pas de statut juridique. Toute stratégie de maintenance devra donc accepter et exploiter ces aspects décentralisés et communautaires du code open source.

Enfin, pour construire un écosystème sain et durable, il sera crucial d’éduquer les gens à ce problème, de faciliter les contributions financières et humaines des institutions, de multiplier le nombre de contributeurs open source et de définir les bonnes pratiques et stratégies au sein des projets qui participent de cette infrastructure.

En 1998, une équipe d’experts en sécurité se constitua au Royaume-Uni pour élaborer une panoplie d’outils de chiffrement libres destinés à Internet.

Très vite, tout le monde se mit à parler de leur projet, intitulé OpenSSL (les développeurs avaient pris comme base de départ un projet australien existant, SSLeay). Non seulement il était complet et relativement fiable, mais il était libre. Il n’est pas facile d’écrire de la cryptographie et OpenSSL avait résolu un problème épineux pour les développeurs du monde entier : en 2014, deux tiers des serveurs web utilisaient OpenSSL, et les sites pouvaient donc transmettre de façon sécurisée les codes de cartes de crédit et autres informations sensibles via Internet.

Pendant ce temps, le projet était toujours géré de façon informelle par un petit groupe de volontaires. Un conseiller du Département de la Défense des États-Unis, Steve Marquess, avait remarqué qu’un contributeur, Stephen Henson, travaillait à temps plein sur OpenSSL. Par curiosité, Marquess lui demanda ce qu’il gagnait, et apprit avec surprise que le salaire de Henson était cinq fois plus faible que le sien.

Marquess s’était toujours considéré comme un bon programmeur, mais ses talents faisaient pâle figure à côté de ceux de Henson. Comme bien d’autres, Marquess imaginait à tort que quelqu’un d’aussi talentueux que Henson aurait un salaire à sa mesure.

Henson travaillait sur OpenSSL depuis 1998. Marquess avait rejoint le projet plus récemment, au début des années 2000, et avait travaillé avec Henson pendant plusieurs années avant d’apprendre sa situation financière.

Comme il avait travaillé avec le Département de la Défense, Marquess savait à quel point OpenSSL était crucial, non seulement pour leur propre système, mais pour d’autres industries dans le monde, de l’investissement à l’aéronautique en passant par la santé. Jusqu’alors, il avait « toujours supposé (comme le reste du monde) que l’équipe d’OpenSSL était grande, active et bien financée. »
En réalité, OpenSSL ne rapportait même pas assez pour payer un seul salarié.

Marquess décida de s’impliquer dans le projet : il avait contribué au code de temps à autre, mais il se rendit compte qu’il serait plus utile en tant qu’homme d’affaires. Il commença par négocier des petits contrats de conseil par le biais d’une entreprise à but non lucratif existante pour maintenir OpenSSL à flot dans ses années les plus dures. Comme le volume des contrats croissait, il créa une entité légale pour collecter ces revenus, l’OpenSSL Software Foundation (OSF).
Malgré le nombre de personnes et d’entreprises qui utilisaient leur logiciel, l’OSF ne reçut jamais plus de 2 000 dollars de dons par an. Les revenus bruts de l’activité de conseil et des contrats ne dépassèrent jamais un million de dollars, qui furent presque entièrement dépensés en frais d’hébergement et en tests de sécurité (qui peuvent coûter plusieurs centaines de milliers de dollars).

Il y avait juste assez pour payer le salaire d’un développeur, Stephen Henson. Cela signifie que les deux tiers du Web reposaient sur un logiciel de chiffrement maintenu par un seul employé à temps plein.

L’équipe d’OpenSSL continua à travailler de façon relativement anonyme jusqu’en avril 2014, quand un ingénieur de chez Google, Neel Mehta, découvrit une faille de sécurité majeure dans OpenSSL. Deux jours plus tard, un autre ingénieur, de l’entreprise finlandaise Codenomicon, découvrit le même problème.
Tous deux contactèrent immédiatement l’équipe d’OpenSSL.

Ce bug, surnommé Heartbleed, s’était glissé dans une mise à jour de 2011. Il était passé inaperçu pendant des années. Heartbleed pouvait permettre à n’importe quel pirate suffisamment doué de détourner des informations sécurisées en transit vers des serveurs vulnérables, y compris des mots de passe, des identifiants de cartes de crédit et autres données sensibles.

Joseph Steinberg, un éditorialiste spécialisé en cybersécurité, écrivit : « on pourrait dire que Heartbleed est la pire vulnérabilité découverte… depuis qu’Internet a commencé à être utilisé pour des opérations commerciales. »

Grâce à un large écho médiatique, le grand public entendit parler de ce bug informatique, au moins de nom. Des plateformes majeures, comme Instagram, Gmail ou Netflix, furent affectées par Heartbleed.

Certains journalistes attirèrent l’attention sur l’OpenSSL lui-même, et la manière dont l’équipe de développement avait lutté pendant des années pour pouvoir continuer ses travaux. Les experts en sécurité connaissaient les limites d’OpenSSL, mais l’équipe ne parvenait pas à capter les ressources ou l’attention adéquates pour résoudre les problèmes.

Marquess écrivit à propos de Heartbleed « ce qui est mystérieux, ce n’est pas qu’une poignée de bénévoles surchargés de travail ait raté ce bug, mais plutôt qu’il n’y a pas eu davantage de bugs de ce genre. »

Les gens envoyèrent des dons pour soutenir la fondation, et Marquess les remercia pour leur enthousiasme, mais le premier cycle de dons ne totalisa qu’environ 9 000 dollars : largement en deçà du nécessaire pour soutenir une équipe dédiée.

Marquess adressa alors à Internet un vibrant plaidoyer pour une levée de fonds :

 

Les gars qui travaillent sur OpenSSL ne sont là ni pour l’argent, ni pour la gloire (qui, en dehors des cercles geeks, a entendu parler d’eux ou d’OpenSSL avant la sortie de heartbleed[sic] dans les médias ?). Ils travaillent pour la fierté de créer et parce qu’ils se sentent responsables de à quoi ils croient.

Il faut des nerfs d’acier pour travailler pendant des années sur des centaines de milliers de lignes d’un code très complexe, où tout le monde peut voir chacune des lignes que vous manipulez, en sachant que ce code est utilisé par des banques, des pare-feux, des systèmes d’armement, des sites web, des smartphones, l’industrie, le gouvernement, partout. Et tout cela en acceptant de ne pas être apprécié à votre juste valeur et d’être ignoré jusqu’à ce que quelque chose tourne mal.

Il devrait y avoir au moins une demi-douzaine de membres à temps plein dans l’équipe au lieu d’un seul pour se consacrer au soin et à la maintenance que demande OpenSSL, sans devoir gérer en même temps l’aspect commercial.

Si vous êtes un décideur dans une multinationale ou un gouvernement, pensez-y. Je vous en prie. Je me fais vieux, je fatigue et j’aimerais prendre ma retraite un jour.

Après Heartbleed, OpenSSL obtint enfin le financement nécessaire – en tous cas jusqu’à présent. L’équipe dispose à l’heure actuelle d’assez d’argent pour payer quatre employés à temps plein pendant trois ans. Mais au bout d’un an et demi de ce financement, Marquess n’est pas certain de l’avenir.

Il a admis que Heartbleed a été une bénédiction pour eux, mais qu’il est « légèrement ironique » que ce soit une faille de cette ampleur qui ait donné plus de visibilité à leur cause. Et quand l’argent sera épuisé et que le monde sera passé à autre chose, Marquess craint qu’ils ne se retrouvent dans la même situation qu’avant Heartbleed, voire pire : la clientèle que Marquess a mis des années à se constituer a disparu, puisque l’équipe travaille maintenant à plein temps sur OpenSSL et n’a plus le temps d’exécuter des contrats.

Marquess lui-même a bientôt l’âge de la retraite. Il est le seul qui accepte de s’occuper des affaires commerciales et du rôle exécutif associés à OpenSSL comme les impôts, la recherche de clients, et la gestion des donateurs. Le reste de son équipe préfère se concentrer sur l’écriture et la maintenance du code. Il ne peut embaucher personne pour le remplacer quand il prendra sa retraite, parce qu’il ne perçoit en ce moment aucun salaire. « Je ne crois pas qu’on puisse tenir comme ça plus d’un an ou deux » a-t-il remarqué.

L’histoire d’OpenSSL n’est pas unique, et par bien des aspects, Marquess trouve que lui et son équipe font partie des mieux lotis. Bien d’autres projets sont toujours en manque de reconnaissance et de financement, alors qu’ils constituent l’infrastructure numérique, infrastructure absolument cruciale puisque tous les logiciels d’aujourd’hui, et par conséquent tous les aspects de notre vie quotidienne, en dépendent.

Relever ses courriels, lire les actualités, vérifier le prix des actions, faire des achats en ligne, aller chez le médecin, appeler le service client – qu’on le réalise ou non, tout ce que nous faisons est rendu possible par des projets comme OpenSSL. Sans eux, la technologie sur laquelle repose la société moderne ne pourrait tout simplement pas fonctionner.

Beaucoup de ces projets sont créés et maintenus par des volontaires et offerts au public gratuitement. Tous ceux qui le veulent, de Facebook au programmeur amateur, peuvent utiliser ce code pour créer leurs propres applications. Et ils le font.

S’il est difficile de croire, comme le dit Marquess, « qu’un groupe hétéroclite d’amateurs puisse faire mieux que de gigantesques sociétés avec leur argent et leurs ressources », voyez plutôt comme c’est lié à la montée en puissance du travail collaboratif pair-à-pair dans le monde.

Des startups jusqu’ici impensables comme Uber ou AirBnB se sont transformées en l’espace de quelques années en poids lourds du monde des affaires et remettent en question des industries phares comme le transport ou l’hôtellerie. Des musiciens se font un nom sur YouTube ou Soundcloud plutôt qu’en passant par les majors. Créateurs et artistes concrétisent leurs idées via des plateformes de financement participatif telles que Kickstarter ou Patreon.

Les autres projets de l’infrastructure sont également issus de la passion et de la créativité de développeurs qui se sont dit : « Je pourrais faire ça mieux », et qui collaborent pour développer et livrer du code au monde entier. La différence, c’est que des millions de personnes ont besoin de ce code dans leur vie quotidienne.

Comme le code n’est pas aussi sexy qu’une vidéo virale sur YouTube ou une campagne Kickstarter, le grand public est très loin de pouvoir l’apprécier à sa juste valeur, si bien que le code qui a révolutionné les technologies de l’information manque très largement du soutien des institutions.

Mais nous ne pourrons ignorer cela plus longtemps.

Ces cinq dernières années, notre dépendance aux logiciels ainsi qu’au code libre et public qui les fait fonctionner s’est accélérée. Les technologies se sont fait une place dans tous les aspects de nos vies, et plus les gens utilisent de logiciels, plus on en crée, et plus cela demande de travail de maintenance.

Toutes les startups qui réussissent ont besoin d’une infrastructure publique pour assurer leur succès, pourtant aucune entreprise n’est assez motivée pour agir seule. Pendant que le monde progresse à toute vitesse vers l’ère moderne des startups, du code et des technologies, l’infrastructure reste à la traîne. Les fissures des fondations ne sont pas encore très visibles, mais elles s’élargissent. Après des années de croissance sans précédent qui nous ont propulsés dans une époque de croissance et de prospérité, nous devons maintenant agir pour nous assurer que le monde que nous avons bâti en si peu de temps ne va pas s’effondrer brutalement sans crier gare.

Pour comprendre comment nous pouvons préserver l’avenir, nous devons d’abord comprendre ce qu’est le logiciel lui-même.

 

(À suivre…)

La semaine prochaine : comment on fabrique des logiciels…

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

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

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

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

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

Par Shubheksha

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

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

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

Oui. Deux ans.

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

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

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

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

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

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

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

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

La réponse que je reçus fut :

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

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

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

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

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

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

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

Ma découverte de Mozilla

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

Bon sang, j’en suis tellement heureuse maintenant.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Conseil n°3 : lancez-vous !

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

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

Merci à tous ceux qui travaillent dans l’open source

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

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

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

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

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

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

Les membres du groupe Framalang ont toujours un gros appétit, il faut à leur insatiable faim de traduction de nouveaux aliments. C’est un morceau de choix qu’ils ont décidé de traduire et publier progressivement ici même…

… un livre entier de Nadia Eghbal qui porte sur l’infrastructure cachée ou discrète de la grande soupe numérique où nous grenouillons. Cet ouvrage a été financé par la Fondation Ford et sa source est sous licence CC BY 4.0, ce qui vous permet d’en profiter.

Si ça vous tente de nous rejoindre dans cette entreprise à long terme (il nous faudra quelques mois et nous n’avons pas de deadline hein) nous diffuserons sur Framasphère l’adresse du framapad de la traduction de la semaine chaque mardi à 19h 😉

 

Nous vous proposons aujourd’hui seulement l’avant-propos.

Histoire de susciter votre curiosité voici quelques titres des chapitres que nous vous proposerons semaine après semaine :

• Une brève histoire du code public et libre et de ceux qui l’ont libéré
• Pourquoi les gens continuent-ils à contribuer à ces projets sans être payés ?
• Comment sont gérés les projets d’infrastructure numérique ?
• Les rapports difficiles de l’open source avec l’argent
• …

 

Des routes et des ponts (1)

Document original (lien direct vers le PDF) Roads and Bridges, The Unseen Labor behind Our Digital Structure
par : Nadia Eghbal

Traduction Framalang : astraia_spica, Mika, peupleLà, roptat, xi, Luc, mika, Lyn., Julien / Sphinx, Lumibd, goofy

Avant-propos

Le problème exposé dans cet ouvrage m’est apparu sur une intuition. Pour avoir travaillé dans des startups puis dans des sociétés de capital-risque, j’ai pu constater que des sommes d’argent considérables affluaient dans les entreprises de logiciel. Par ailleurs, en tant que développeuse de logiciel en amateur, j’étais bien consciente que je n’aurais rien pu produire toute seule. J’utilisais du code gratuit et public (plus connu sous le nom de code open source) dont j’assemblais des éléments afin de répondre à des objectifs personnels ou commerciaux. Et franchement, les personnes impliquées dans ces projets avaient, quel que soit leur rôle, fait le plus gros du travail.

Cette observation m’a tourné dans la tête pendant plusieurs années, tandis que j’assistais à l’explosion à droite et à gauche des bootcamps où étaient diplômés de nouveaux développeurs de logiciel et que je voyais des startups lever plusieurs dizaines de millions de dollars pour vendre des produits qui tournaient sans doute avec plus de code libre que de code propriétaire. Ayant précédemment travaillé dans des associations à but non lucratif, je faisais immédiatement le lien avec les biens publics et les défis qui leur sont associés. Pourtant ce vocabulaire était étrangement absent du langage de mes pairs dans le monde du logiciel.

Après avoir quitté mon travail dans une entreprise de capital-risque l’an dernier, je me suis mis en tête d’étudier ce paradoxe auquel je ne cessais de penser : il existe des logiciels précieux qui ne peuvent pas s’appuyer sur des modèles commerciaux et auxquels manquent le soutien des pouvoirs publics.

C’est plutôt amusant, mais le code open source ne figurait pas sur ma liste initiale. Comme mes collègues, j’avais supposé, à tort, que c’était l’exemple même de ressources logicielles à la disposition du public qui bénéficiaient d’un fort soutien. Lorsque j’ai mentionné l’open source à mes amis et mentors, ils m’ont aimablement dissuadée de poursuivre mes recherches dans ce domaine, puis incitée à plutôt trouver d’autres exemples de domaines qui avaient vraiment besoin de soutien.

Pourtant, je suis tombée sur un certain nombre de projets open source qui mettaient à mal ces préjugés. Il s’est avéré que maintenir les projets dans la durée était un problème connu dans le monde des contributeurs de l’open source. Plus je creusais la question et plus je découvrais des billets de blog, des articles et des forums de discussion qui abordaient la tension et l’épuisement éprouvés par ceux qui maintiennent les projets open source. Tout le monde m’indiquait une autre personne à contacter et sans m’en apercevoir j’ai récolté un nombre incroyable de témoignages à ce sujet.

Je me suis rendu compte que j’avais découvert un problème certes « bien connu » des producteurs (les contributeurs de l’open source) mais dont les consommateurs (les entreprises de logiciels et les autres utilisateurs de code open source) n’avaient apparemment aucune idée. Cette anomalie m’a incitée à me pencher sur le problème.

Par ailleurs, il semble que le milieu de l’open source soit lui-même en train d’évoluer, voire de bifurquer. J’ai eu des conversations très diverses avec des interlocuteurs de différentes générations, tous contributeurs open source. Ils semblaient avoir des philosophies et des valeurs divergentes, au point de donner l’impression de ne pas utiliser le même vocabulaire. J’ai appris que dans les trois à cinq dernières années, la production ainsi que la demande avaient explosé dans le monde de l’open source grâce à l’amélioration des outils pour les développeurs et à celle de l’organisation du travail. Les contributeurs de l’open source d’aujourd’hui sont très différents de ceux d’il y a 10 ans, sans parler de ceux d’il y a 30 ans. Or ces différentes générations ne communiquent pas entre elles, ce qui rend difficile toute conversation productive sur la maintenance pérenne des logiciels.

Au hasard d’une conversation avec Ethan Zuckerman, du MIT Center for Civic Media, j’ai eu l’occasion de partager plus largement mes découvertes.

Bien que ne sachant pas exactement ce qu’il y avait derrière ni si j’employais les bons mots, j’ai décrit à Ethan le problème dont je m’étais rendu compte et il a eu la gentillesse de me mettre en contact avec Jenny Toomey de la Fondation Ford. Jenny m’a suggéré de rassembler les résultats de mes recherches dans un rapport. Au fur et à mesure de son écriture a émergé cet ouvrage sur notre société numérique moderne, et sur l’infrastructure cachée qui la sous-tend.

Le présent ouvrage n’aurait jamais vu le jour si Ethan et Jenny n’avaient pas donné sa chance à une idée tout juste ébauchée qui désormais, grâce au travail d’écriture, s’est transformée en quelque chose de construit. Je les remercie énormément d’avoir fait confiance à leur intuition. Je suis aussi reconnaissante envers Michael Brennan et Lori McGlinchey pour leurs conseils, leur regard, et leur enthousiasme au cours de la relecture. Enfin, et c’est sans doute le plus important, j’ai une dette envers toutes les personnes qui travaillent dans l’open source et qui ont rendu leur histoire publique pour que des gens comme moi puissent la lire — et particulièrement ceux qui ont pris de leur temps malgré un agenda chargé pour me divertir au détour d’une conversation ou d’un courriel. Ce rapport est un concentré de leur sagesse et non de la mienne. Je suis particulièrement reconnaissante pour les conversations que j’ai pu avoir avec Russel Keith-Magee, Eric Holscher, Jan Lehnardt, Audrey Petrov et Mikeal Rogers, ils continuent à m’inspirer par leur patience et leur dévouement à l’égard du travail open source.

Merci d’avoir été aussi attentionnés.

Si vous avez raté le début…

(Si vous avez déjà suivi les épisodes précédents, allez directement au texte de David…)

Comme le savent nos lecteurs, nous défendons volontiers non seulement les logiciels mais aussi la culture libre sous ses multiples formes, y compris dans le domaine artistique :

la position et l’expérimentation d’artistes comme Gwenn Seemel, Amanda Palmer, Neil Jomunsi entre autres multiples exemples (ne risquons pas l’accusation de copinage en mentionnant Pouhiou), nous intéressent et nous passionnent parce qu’elles témoignent d’un monde à la charnière. En effet, un modèle d’édition et de diffusion arrive en bout de course et à bout de souffle, mais il est défendu mordicus à la fois par ses bénéficiaires (c’est cohérent) et parfois par ses victimes, ce qui est plus surprenant. Quant aux modèles émergents, aux variantes nombreuses et inventives, ils cherchent la voie d’une viabilité rendue incertaine par les lois du marché qui s’imposent à eux.

Le mois dernier une annonce nous a fait plaisir, celle de la publication « papier » par Glénat du webcomic Pepper et Carrot de David Revoy, qui n’est pas un inconnu pour les lecteurs du Framablog auquel il a accordé cette interview il y a quelques mois. Voici la page où il détaille sa philosophie.

Un article de Calimaq expose de façon documentée l’intérêt de cette reprise d’une œuvre open source par un éditeur « classique » dans laquelle il voit de façon optimiste une façon de faire bouger les lignes qui bénéficie autant à l’auteur (qui renforce ses sources de mécénat) qu’à l’éditeur et aux lecteurs.

Tout va donc pour le mieux dans le petit monde de la BD ? — Pas vraiment, parce que l’accord passé par David Revoy avec Glénat (lequel s’engage à respecter cette licence Creative Commons) vient de provoquer une levée de boucliers chez un certain nombre d’auteurs de bande dessinée. Ils estiment notamment que cet accord dévalorise l’ensemble d’une profession qui peine déjà à survivre et s’insurgent contre l’idée de donner librement le fruit d’un travail artistique.

Vous pouvez par exemple lire ce billet de Xavier Guilbert pour la revue Du9 qui résume de façon assez équilibrée l’ensemble de la polémique. Si vous souhaitez lire un avis circonstancié carrément libriste, lisez l’excellent coup de gueule de Luc, qui fait notamment le lien avec Framabook, notre maison d’édition qui a fait « le pari du livre libre », mais établit néanmoins des contrats avec les auteurs qui sont rémunérés.

Également du côté des défenseurs du libre Neil Jomunsi sort la grosse artillerie et demande aux auteurs de se sortir les doigts du c**. C’est précisément à la suite de cet article que le principal intéressé s’exprime dans un long commentaire que nous reproduisons ici avec son accord.

(dans un premier temps David s’adresse à Neil Jomunsi)

Hello, merci Neil pour cette initiative, j’espère y lire ici des propositions constructives de la part des autres auteurs et non pas seulement des retours des happy few qui vivent confortablement du système éditorial classique. En effet, je prends en considération que ces auteurs ne peuvent pas émettre une pensée libre d’intérêts éditoriaux ou syndicaux sur ce thème (surtout de manière publique). Ils ont aussi très peu d’intérêt à un changement de paradigme…
Pour ma part, je me suis très peu exprimé jusqu’alors. Mais je me sens à l’aise sur ce blog. J’aime le ton de l’article, la police d’écriture et la boîte de commentaire large. Je pense que ça risque de me faire pianoter. Et puis, je n’ai pas de blog français… Je réquisitionne donc cette boîte de commentaire un peu comme un blogpost de réponse.

 

Voici mon angle de vue que-personne-ne-m’a-demandé-mais-voilà-tout-de-même sur le modèle de Pepper&Carrot et pourquoi, je le répète, il me convient et que je maintiens ma tag-line sur ma page de garde :

(Note : j’utiliserai par raccourcis les termes ‘auteurs’, ‘éditeurs’, ‘lecteurs’, mais je pense bien également aux ‘autrices’, ‘éditrices’, ‘lectrices’ derrière ces termes.)

Donc entendons-nous bien ici : je ne suis pas dans une lutte classique tel qu’on l’entend, voulant la destruction d’organisations, d’entreprises ou autre systèmes en place. Dans « changer l’industrie de la BD », j’entends « sanifier » les relations auteurs/éditeurs par plus de liberté et d’indépendance dans leurs relations. Par sanifier, je n’entends pas l’inversion du rapport de force où l’auteur triomphe de l’éditeur. Non. Dans ma démarche, il n’y a pas de rapport de force entre auteur et éditeur. L’éditeur est un acteur libre qui fait un produit dérivé de ma création. Dans le système classique, il y a un rapport dominant/dominé évident, contractualisé et opaque aux lecteurs. C’est tout là le problème. Avec Pepper&Carrot, je propose un système côte-à-côte. Chacun indépendant.

Ce système marche-t-il ? Sur ma page Philosophie, j’écris

… Et pourquoi Pepper&Carrot ne pourrait-il pas amorcer un changement et ainsi inspirer une industrie en crise ? Essayons !

Ce « essayons » démontre le caractère expérimental de ma démarche. Car oui, je suis en train de créer, oui, c’est nouveau et oui, ça agace quand quelqu’un essaie du nouveau.

Pepper&Carrot est un webcomic numérique en anglais principalement et international. Il est hébergé autant à Paris, qu’au U.S.A, en Asie et sur je-ne-sais-combien de sites miroirs et ça tourne. La France représente 4 % de ses visiteurs et cela me donne un peu de retrait sur le problème actuel. En effet : il serait vraiment malhonnête de penser que je suis dans la même situation qu’un jeune dessinateur amateur français, publiant en français sans audience et qui n’aurait qu’un seul éditeur monolithique comme source de revenus/diffusion, Glénat, pour survivre avec les 350 $ par mois de mécénat de Glénat… C’est pourtant, et à l’origine du buzz, l’angle de communication surprenant qu’a essayé d’orchestrer le syndicat BD SNAC sur sa page Facebook, et ce, bizarrement à quelques dizaines de jours d’une rencontre auteurs/éditeur importante. À part m’y faire traiter littéralement de con dans les commentaires et d’amener un lectorat d’auteurs entier à mépriser ma démarche, rien n’a germé, aucune pensée : stérile. Cependant cela a alimenté de la colère. Ce groupe a-t-il besoin de ça pour s’unifier ? Pepper&Carrot/Glénat est simplement devenu un prétexte du moment. Une opportunité pour eux de « casser de l’éditeur » collectivement et dénigrer un nouvel auteur qui n’a pas choisi de lutter à leur manière. Triste.

Donc ce buzz, dit il la vérité ? En partie, oui, c’est pour ça que ça marche. Il est possible à n’importe qui de faire des produits dérivés de Pepper&Carrot, de façon commerciale, en suivant un ensemble de règles de la Creative Commons Attribution permissive que j’ai établie. Glénat qui imprime à 10 000 exemplaires mon webcomic n’est qu’un produit dérivé à mes yeux (comme déjà dit). Pour faire un parallèle, je le considère comme si j’avais un film et qu’ils imprimaient la figurine du héros. Rien de plus. Nous avons eu une collaboration que je décris en anglais sur le blog de Pepper&Carrot. J’en suis satisfait, c’est super cool un premier album imprimé, mais cliquez sur le bouton « HD » sur le site de Pepper&Carrot, et vous y aurez plus de détails, plus de couleurs que dans l’album imprimé.

Ma BD principale, mon support de choix n’est pas l’album de Glénat. Ce n’est pas le média principal de Pepper&Carrot. D’autres projets suivront comme l’éditeur allemand Popcom qui vient de rejoindre le mécénat de Pepper&Carrot, le livre de la Krita Foundation ou une édition régionale en Breton de Pepper&Carrot. Ce n’est que le début, le projet n’a que deux ans et je ne compte pas tout ça comme un manque à gagner. Je n’y vois que les effets positifs de personnes qui utilisent la base de ressources que j’ai créée, avec respect, dans les règles qui me conviennent pour créer plus de valeur autour de la série. Et ça fonctionne.

Glénat fait des bénéfices ? Et alors ? Bon pour eux. Le font-il « sur mon dos » ? Non, je ne me sens pas lésé en quoi que ce soit. Pas plus que quand Pepper&Carrot fait la frontpage d’ImgUr, de deviantArt ou de Reddit. (je vous présente ici des nouvelles puissances éditoriales). Le papier, la chaîne graphique, l’impression, l’empaquetage, la distribution, etc. c’est le métier de l’éditeur, il véhicule mon œuvre sur le papier. Pas très différent de ce que ferait un autre site web, pour moi. De mon point de vue, je fais du divertissement numérique sur Internet et je ne vends pas de BD. Si l’éditeur aime la source qui lui permet de vendre du papier, il sait comment me gratifier. Idem pour l’audience. C’est simple et c’est décrit dans l’album papier de Glénat Pepper&Carrot (si certains avaient pris le temps de l’ouvrir). Ce qui m’interpelle vraiment, c’est : Glénat imprime 10 000 exemplaires et aucun petit éditeur ne pense à aller sur mon site télécharger plein de croquis Creative Commons et en faire un artbook d’accompagnement en librairie ? Publier des cartes postales ? Refaire une version « deluxe » du Tome 1 ? Le monde éditorial à moins d’initiative que ce que j’avais prévu.

Je veux un univers collaboratif dont le lecteur puisse s’imprégner et devenir à son tour acteur, entrepreneur. Ici encore la Creative Commons Attribution le permet

J’aimerais aussi faire prendre conscience dans ce débat sur un autre point qui n’est jamais abordé dans les articles : la « culture libre » que permet Pepper&Carrot. Les auteurs ont conquis une place dans les esprits de leurs audiences qui me dérange fondamentalement. Prenez par exemple une BD lambda, distribué sous copyright classique (même d’un webcomic « gratuit » mais propriétaire d’Internet). Tout le monde peut penser l’univers, rêver dedans, rejouer les scènes en pensée, etc. Cet univers existe en nous. Mais dès que cette pensée essaie de germer, de muter, de passer à l’action dans la vraie vie par une création, elle se retrouve anéantie ou réduite aux règles vaseuses du fair-use/fan-art/fan-fiction qui devient illégal en cas de création d’activité commerciale. Combien de cas problématiques sur Internet ces dernières années ! Sans le savoir, les auteurs d’univers propriétaire sont aussi propriétaires d’une part de votre culture, de votre pensée, de vos rêves, de ce qui regroupe les fans…

Avec Pepper&Carrot, je ne veux plus de ce paradigme du tout. Je veux un univers collaboratif dont le lecteur puisse s’imprégner et devenir à son tour acteur, entrepreneur. Ici encore la Creative Commons Attribution le permet, et ainsi j’ai des projets de jeux vidéos, de jeux de sociétés, de jeux de rôles de fan-art et de fan-fictions qui viennent à leur tour enrichir le wiki de l’univers d’Hereva à la base de Pepper&Carrot. Encore une fois, ceci est ma volonté de créer une relation côte-à-côte avec le lecteur, et j’en vois les bénéfices.

je replace l’auteur maître de son œuvre en face de l’éditeur dans un rapport d’égal à égal dans leur liberté et leurs droits.

Vous l’avez donc compris, je ne suis pas intéressé par l’établissement d’une relation d’un contrat classique, dominant-éditeur, dominé-auteur et sous-dominé-lecteur-acheteur. C’est liberticide et nuirait collectivement à notre éditeur-auteur-lecteur, à nos libertés d’agir, d’entreprendre et de penser. Je fonde un écosystème où les acteurs sont libres et côte-à-côte dans un rapport pacifié. La CC-By-Nc ? (la clause non-commerciale de la Creative Commons) désolé, je ne la veux pas pour ma BD, et ce n’est pas parce que ça s’appelle Creative Commons que c’est libre : c’est une licence propriétaire. La CC-By (attribution) est libre et m’intéresse. Avec cette liberté, cette indépendance, j’ai ici un modèle qui fonctionne à ma modeste échelle et tout ceci alimenté financièrement grâce à des héros dans mon audience qui soutiennent mon travail et ma philosophie.

 

Mais ce n’est pas tout… Ce que je propose est une solution robuste contre la question du piratage de la BD, ce que je propose rend obsolète la création même des DRM pour la diffusion numérique, ce que je propose clarifie les rapports ambigus pour la création de fan-art/fan-fiction et dérivations, et enfin je replace l’auteur maître de son œuvre en face de l’éditeur dans un rapport d’égal à égal dans leur liberté et leurs droits.

Refaites le compte, et réévaluez ma proposition. Libre aussi à chacun de signer un contrat, de le négocier, de savoir quoi faire avec son œuvre. Mais pour moi, cette réflexion est faite. J’aime le libre pour ce qu’il offre pragmatiquement et je suis déjà dans son application à la réalité concernant ma BD depuis deux ans. Il vous reste un dégoût qu’une grosse entreprise genre « gros éditeur » puisse imprimer vos œuvres gratuitement ? Cela fait partie de la licence libre telle qu’elle est et de la liberté qu’elle offre. La licence n’est qu’un outil ne peut pas faire vraiment de différence entre la lectrice/traductrice japonaise, le petit commerçant polonais, l’artisan irlandais, le gros site web australien et le géant industriel de l’édition française… Sinon ce ne serait plus de la vraie liberté.

Il ne me reste plus qu’à continuer d’informer les lecteurs et leur demander de soutenir les artistes libres qu’ils aiment directement via Internet et non de penser que ces artistes touchent un quelconque gros pourcentage opaque sur les produits dérivés que ceux-ci iront acheter. Cette tâche d’information, si on s’y mettait tous collectivement et pratiquement entre artistes, aurait certainement plus d’effets sur nos niveaux et confort de vie que toutes négociations de pourcentages et discussions de frais d’avances autour de réunions et de cocktails.

 

• Toutes les illustrations de cet article sont de David Revoy, CC-BY

Le groupe Framalang a traduit l’article de Julien, qui a listé tous les moyens de se tirer une balle dans le pied quand on coordonne un projet libre.

Apprenez à les éviter !

Conduite de projets Open Source : 10 erreurs à éviter

Article original : https://julien.danjou.info/blog/2016/foss-projects-management-bad-practice
Auteur : Julien Danjou(CC-BY-SA)
Traduction : lyn., KoS, AlienSpoon, David 5.1, Simon, goofy, Slimane Aguercif, Fred, galadas, terhemis, gégé

Il y a quelques semaines, lors de l’OpenStack Summit (réunion annuelle des contributeurs à OpenStack, NDT), j’ai eu l’occasion de discuter de mon expérience de la conduite de projets Open Source. Je me suis rendu compte qu’après avoir fait partie de plusieurs communautés et beaucoup contribué pendant des années, je pourrais faire profiter les nouveaux venus de conseils et d’avis expérimentés.

Il existe une foule de ressources disponibles expliquant comment conduire un projet Open Source. Mais aujourd’hui, je voudrais aborder ce sujet sous un angle différent, en insistant sur ce qu’il convient de ne pas faire avec les personnes qui y participent. Je tire cette expérience des nombreux projets Open Source auxquels j’ai participé ces dernières années. Je vais décrire, sans ordre particulier, quelques mauvaises pratiques que j’ai constatées, en les illustrant par des exemples concrets.

 

1. Considérer les contributeurs comme une nuisance

Quand les informaticiens sont au travail, qu’ils soient chargés du développement ou de la maintenance d’un logiciel, il est une chose dont ils n’ont pas besoin : du travail supplémentaire. Pour la plupart d’entre eux, la première réaction à toute contribution externe est : « Zut, du travail en plus ». Et c’est effectivement le cas.

Par conséquent, certains développeurs essayent d’éviter ce travail supplémentaire : ils déclarent ne pas vouloir de contributions, ou font en sorte que les contributeurs se sentent indésirables. Cela peut prendre de nombreuses formes, comme les ignorer ou être désagréable avec eux. Ainsi, les développeurs évitent d’avoir à traiter le surplus de travail qu’on leur met sur le dos.

C’est une des plus grandes erreurs que l’on peut commettre, et une vision fausse de l’Open Source. Si des gens vous apportent du travail supplémentaire, faites tout ce que vous pouvez pour bien les accueillir afin qu’ils continuent à travailler avec vous. Il s’agit peut-être de ceux qui prendront votre relève d’ici peu. Préparez votre future retraite.

Prenons le cas de mon ami Gordon, que j’ai vu démarrer en tant que contributeur sur Ceilometer en 2013. Il examinait très bien le code, si bien qu’il me donnait en fait davantage de travail : non seulement en détectant les anomalies dans mes contributions, mais aussi en me faisant vérifier les siennes. Au lieu de m’en prendre à lui pour qu’il arrête de me faire retravailler mon code et vérifier ses correctifs, j’ai proposé qu’on lui fasse davantage confiance en l’ajoutant officiellement à l’équipe des correcteurs sur un des projets.

Et s’ils ne font pas cette première contribution, ils ne feront pas non plus la seconde. En fait, ils n’en feront aucune ; et ces projets perdraient alors leurs futurs correcteurs.

2. Ne confier aux autres que le sale boulot

Lorsque de nouveaux contributeurs se présentent pour travailler sur un certain projet, leurs motivations peuvent être très diverses. Certains sont des utilisateurs, d’autres veulent simplement voir ce que c’est de contribuer. Ressentir le frisson de la participation, comme un simple exercice ou avec la volonté d’apprendre afin de contribuer en retour à l’écosystème qu’ils utilisent.

En général, les développeurs confient le sale boulot à ces personnes, c’est à dire des tâches sans intérêt, à faible valeur ajoutée, et qui n’auront sans doute aucun impact direct sur le projet.

Pour certains, ce n’est pas grave, pour d’autres, ça l’est. Certains seront vexés de se voir confier du travail sans grand intérêt, alors que d’autres seront heureux de le faire pourvu qu’on leur témoigne de la reconnaissance. Soyez sensible à cela, et félicitez ces personnes. C’est la seule manière de les garder dans le projet.

3. Mépriser les petites contributions

Quand le premier patch d’un nouveau contributeur est une correction d’orthographe, qu’en pensent les développeurs ? Qu’ils s’en fichent, que vous gâchez de leur temps précieux avec votre petite contribution. Et personne ne s’intéresse à la perfection grammaticale d’une documentation, n’est-ce pas ?

C’est faux. Voyez mes premières contributions à home-assistant et Postmodern : j’ai corrigé des fautes d’orthographe dans la documentation.

J’ai contribué au projet Org-mode pendant quelques années. Mon premier patch corrigeait simplement une chaîne de caractères du code. Ensuite, j’ai envoyé 56 patchs, corrigeant des bogues et ajoutant de nouvelles fonctionnalités élégantes, et j’ai aussi codé quelques extensions. À ce jour, je suis toujours seizième dans la liste des plus gros contributeurs d’Org-mode, qui en contient 390. Certainement pas ce qu’on appellerait un petit contributeur, donc. Je suis sûr que la communauté est bien contente de n’avoir pas méprisé ma première correction dans la documentation.

4. Mettre la barre trop haut pour les nouveaux arrivants.

Quand de nouveaux contributeurs arrivent, leurs connaissances du projet, de son contexte, et des technologies sont très variables. L’une des erreurs que les gens font le plus souvent consiste à demander aux nouveaux contributeurs des choses trop compliquées, dont ils ne pourront pas venir à bout. Cela leur fait peur (surtout les timides ou les introvertis) et ils risquent de disparaître, se croyant trop stupides pour aider.

Avant de faire le moindre commentaire, vous ne devriez avoir strictement aucun a priori sur leur niveau. Cela permet d’éviter ce genre de situations. Il faut également mettre beaucoup de délicatesse quand vous estimez les compétences des nouveaux, car certains pourraient se vexer si vous les sous-estimez trop.

Quand son niveau est bien estimé (un petit nombre d’échanges devrait suffire), vous devez former votre contributeur en ne le guidant ni trop ni trop peu, afin qu’il puisse s’épanouir. Il faut du temps et de l’expérience pour y parvenir, et vous allez probablement perdre certains contributeurs avant de bien maîtriser ce processus, mais c’est un chemin que tous ceux qui gèrent des projets doivent suivre.

Façonner ainsi les nouveaux arrivants est au cœur de la gestion de vos contributeurs, et ce quel que soit votre projet. Et je suis quasiment sûr que cela s’applique à tout projet, même en dehors du logiciel libre.

5. Exiger des gens qu’ils fassent des sacrifices sur le plan personnel

C’est un point qui dépend beaucoup du projet et du contexte, mais il est très important. Dans le logiciel libre, où la plupart des gens vont contribuer par bonne volonté et parfois sur leur temps libre, vous ne devez surtout pas exiger d’eux qu’ils fassent des sacrifices personnels importants. Ça ne passera pas.

L’une des pires manières de faire cette erreur est de fixer un rendez-vous à l’autre bout du monde pour discuter du projet. Cela place les contributeurs qui vivent loin dans une situation injuste, car ils ne peuvent pas forcément quitter leur famille pour la semaine, prendre l’avion ou un autre moyen de transport, louer une chambre d’hôtel… Ce n’est pas bon : tout devrait être mis en œuvre pour que les contributeurs se sentent partie prenante du projet et intégrés à la communauté, sans que l’on exige cela de leur part. Entendons-nous bien, cela ne veut pas dire qu’il faut s’interdire toute rencontre ou activité sociale, au contraire. Pensez simplement à n’exclure personne lorsque vous discutez d’un projet.

Il en va de même pour les moyens de communication susceptibles de compliquer la vie des participants : se retrouver sur IRC (il est difficile pour certaines personnes de réserver une heure, surtout lorsqu’il faut tenir compte des différents fuseaux horaires), faire une visioconférence (en particulier quand on n’utilise pas de logiciel libre et gratuit), etc.

En gros, tout ce qui impose de se synchroniser en temps réel avec l’avancement du projet est contraignant pour certains contributeurs.

C’est pourquoi le meilleur moyen de communiquer reste le courriel, mais tous les outils de communication asynchrones (pisteurs de bogues, etc.) feront l’affaire dans la mesure où ils permettent à chacun de travailler à son rythme et à l’heure qui lui convient.

6. Ne pas avoir de code de conduite

À une époque où de plus en plus de communautés s’ouvrent à un public plus large que celui auquel elles étaient habituées (ce qui est fantastique), les codes de conduite semblent être un sujet à la mode, mais aussi délicat.

En réalité, toutes les communautés ont un code de conduite, qu’il soit inscrit noir sur blanc ou suivi inconsciemment par chacun. Sa forme dépend de la taille et de la culture de la communauté.

Cependant, en fonction de la taille de votre communauté et de la façon dont ce code s’applique, vous auriez peut-être intérêt à l’écrire dans un document, comme l’a par exemple fait Debian.

Ce n’est pas parce que vous aurez rédigé un code de conduite que tous les membres de votre communauté vont soudain se transformer en adorables Bisounours le suivant à la lettre, mais il fournit des règles que vous pouvez citer en cas de besoin. Il peut être utile de le transmettre à certains pour leur faire comprendre que leur comportement ne convient pas, et cela peut aider si une exclusion devient nécessaire, même s’il ne sert que rarement à cela, puisqu’en général personne ne veut aller aussi loin.

Je pense qu’on peut très bien se passer d’un tel document sur de petits projets. Mais vous devez garder à l’esprit qu’un code de conduite implicite découlera de votre comportement. La manière dont vos membres les plus influents communiqueront avec les autres installera l’ambiance à travers tout le réseau. Ne sous-estimez pas cela.

Quand nous avons commencé le projet Ceilometer, nous avons suivi le code de conduite du projet OpenStack avant même qu’il ait été écrit, et probablement avons-nous même placé la barre un peu plus haut. En étant agréables, accueillants et ouverts d’esprit, nous avons réussi à obtenir une certaine mixité, avec plus de 25% de femmes dans notre équipe permanente — bien au dessus de la moyenne actuelle d’OpenStack et de la plupart des projets de logiciel libre !

7. Mettre les non-anglophones à l’écart

Il est important d’être conscient que la grande majorité des projets de logiciel libre utilisent l’anglais en tant que langue de communication principale. C’est logique. C’est une langue répandue, et qui semble remplir ce rôle correctement.

Mais une grande partie des codeurs n’ont pas l’anglais pour langue maternelle. Beaucoup ne le parlent pas couramment. Cela signifie que le rythme auquel ils peuvent converser peut-être très lent, ce qui peut en frustrer certains, notamment ceux qui sont nés en terre anglophone.

 

On peut observer ce phénomène dans les rencontres de codeurs, lors de conférences par exemple. Quand les gens débattent, il peut être très difficile pour certains d’expliquer leurs pensées en anglais et de communiquer à un rythme correct, ce qui ralentit la conversation et la transmission des idées. La pire chose qu’un anglophone puisse faire dans ce cas est de leur couper la parole, ou de les ignorer, pour la seule raison qu’ils ne parlent pas assez vite. Je comprends que cela puisse être frustrant, mais le problème n’est pas la façon de parler des non-anglophones mais les outils de communication utilisés qui ne mettent pas tout le monde au même niveau en privilégiant des conversations orales.

La même chose s’applique, à un moindre degré, aux rencontres sur IRC, qui sont relativement synchrones. Les médias complètement asynchrones ne pâtissent pas de ce défaut, et c’est pourquoi ils faudrait, à mon avis, les privilégier.

8. Pas de vision, aucune délégation des tâches

C’est une autre grosse erreur de gestion si le responsable ne parvient pas à gérer la croissance du projet alors que des gens sont disponibles et prêts à aider.

Évidemment, lorsque le flux des contributeurs commence à grossir, ajoutant de nouvelles fonctionnalités, demandant des retours et des instructions à suivre, certains responsables se retrouvent la tête sous l’eau et ne savent pas comment répondre. Ce qui a pour conséquences de frustrer les contributeurs, qui vont simplement partir.

Il est important d’avoir une vision de votre projet et de la communiquer. Dites clairement à vos contributeurs ce que vous voulez, et ne voulez pas, dans votre projet. Exprimer ces informations de manière claire (et non-agressive !) permet de minimiser les frictions entre vos contributeurs. Ils vont vite savoir s’ils veulent rejoindre ou non votre navire et quoi en attendre. Donc, soyez un bon capitaine.

S’ils choisissent de travailler avec vous et de contribuer, vous devez rapidement commencer à croire en eux et à leur déléguer certaines de vos responsabilités. Cela peut être n’importe quelle tâche que vous faites d’habitude vous-même : vérifier les patchs de certains sous-systèmes, traquer les bogues, écrire la documentation… Laissez les gens s’approprier entièrement une partie du projet car ils se sentiront responsables et ils y mettront autant de soin que vous. Faire le contraire en voulant tout contrôler vous-même est la meilleure façon de vous retrouver seul avec votre logiciel open source.

Aucun projet ne va gagner en taille et en popularité de cette manière.

En 2009, quand Uli Schlachter a envoyé son premier patch à awesome, cela m’a donné plus de travail. J’ai du vérifier son patch, et j’étais déjà bien occupé pour sortir la nouvelle version d’awesome sur mon temps libre en dehors de mon travail ! Le travail d’Uli n’était pas parfait, et j’ai eu à gérer les bogues moi-même. Plus de travail. Alors qu’ai-je fait ? Quelques minutes plus tard, je lui ai répondu en lui envoyant un plan de ce qu’il devait faire et de ce que je pensais de son travail.

En retour, Uli envoya d’autres patchs et améliora le projet. Savez-vous ce que fait Uli aujourd’hui ? Il est responsable du gestionnaire des fenêtres awesome à ma place depuis 2010. J’ai réussi à transmettre ma vision, déléguer, puis à quitter le projet en le laissant dans de bonnes mains !

9. Ignorer certains types de contributions

Les gens contribuent de différentes manières, et pas toujours en codant. Il y a beaucoup de choses autour d’un projet de logiciel libre : la documentation, le tri de bogues, le support, la gestion de l’expérience utilisateur, la communication, les traductions…

Par exemple, il a fallu du temps pour que Debian songe à donner le statut de Développeur Debian à leurs traducteurs. OpenStack prend la même direction en essayant de reconnaître les contributions autres que techniques.

Dès lors que votre projet commence à récompenser certaines personnes et à créer différents statuts dans la communauté, vous devez faire très attention à n’oublier personne, car c’est le meilleur moyen de perdre des contributeurs en chemin.

10. Oublier d’être reconnaissant

Cette liste est le fruit de nombreuses années de bidouillages open source et de contributions à des logiciels libres. L’expérience et le ressenti de chacun sont différents, et les mauvaises pratiques peuvent prendre différentes formes : si vous connaissez ou si vous avez vous-même rencontré d’autres obstacles dans vos contributions à des projets open-source, n’hésitez pas à compléter la liste dans les commentaires. C’est une forme de contribution.

 

 

Quand le Framablog est né, le premier article, signé par Alexis Kauffmann, marquait un tournant important de l’association Framasoft, qui passait de la défense et illustration du logiciel libre à un champ plus large, celui de la culture libre.

Dix ans et deux mille articles plus tard ou presque, nous avons eu envie de marquer le coup pour le numéro du 11 septembre.

Pas un bilan.

Pas un bulletin de triomphe autosatisfait.

Pas un dépotage de statistiques avec courbe serpentiforme et camembert multicolore.

Pas non plus une analyse sociologique du lectorat suivant des tranches d’âge et des catégories socio-professionnelles.

Plutôt un point d’étape avec vous.

Vous, lecteurs occasionnels ou réguliers, ceux qui le lisent depuis 2006 et ceux qui viennent de le découvrir, ceux qui sont déjà bien plus loin sur la voie du Libre et ceux qui entament timidement le chemin.

Vous qui enrichissez les publications de commentaires trollesques ou hyperpointus.

Vous grâce à qui peu à peu ce blog n’est plus seulement l’écho de Framasoft mais aussi un regard sur le monde du Libre, ses réussites, ses combats et ses perspectives.

Vous qui faites que ce blog devient et deviendra de plus en plus collaboratif en ouvrant ses colonnes à des interviews, des personnalités, des débats et des initiatives…

Bref, si le succès et l’intérêt du Framablog c’est vous, c’est à vous de nous dire un mot pour son anniversaire.

L’article jalon anniversaire, c’est vous qui allez l’écrire, à plusieurs mains.

… vous avez seulement jusqu’au 4 septembre ! Et ensuite on vous prépare la compil des réponses, un remix de vos mots, un mashup de vos critiques éclairées ou obscures, une macédoine de vos zopignons sur rue, un bazar de réactions dressées comme un lit en cathédrale.

L’article anniversaire sera la voix collective des lecteurs.

À vous de jouer !

Il vous suffit d’utiliser librement ce formulaire

(ben oui un Framaform, qu’est-ce que vous croyez ?)

Vous connaissez l’adage ? « Si le téléphone est intelligent, c’est que l’utilisateur est stupide. » Malheureusement, il se vérifie dans la manière dont les entreprises qui conçoivent ces ordinateurs de poche (avec option téléphone) nous traitent…

Entre la prison dorée qu’est l’Iphone d’Apple (qu’il nous faut « jailbreaker » pour un tout petit peu plus de contrôle, ce qui signifie en Français qu’on en « brise les barreaux »), l’espionnage total de Google sur les Android, les autorisations hallucinantes que nous demandent les applications propriétaires, l’esclavagisme qui se cache derrière les matériaux et la construction, l’obsolescence programmée… difficile de trouver un ordiphone qui convient à nos choix éthiques.

Gee, notre illustrateur-auteur-docteur maison, est parti à la quête d’un smartphone (et de ses logiciels) qui respecterait ce lourd cahier des charges. Nous reproduisons ici un article (libre, bien entendu) paru sur son blog, qui nous offre un retour d’expérience très personnel.

N’hésitez pas à ajouter vos astuces, alternatives, choix et bonnes adresses dans les commentaires !

Fairphone : un téléphone pour libriste ?

Aujourd’hui, je vous propose un petit retour sur le Fairphone 2 qui est devenu mon téléphone il y a un mois de cela. Bon, je n’ai jamais fait d’article de ce genre alors désolé si c’est un peu décousu. Je précise d’emblée que ce n’est absolument pas un article sponsorisé ou commandé, c’est juste un retour spontané parce que je pense que cela peut en intéresser certains (les libristes en premier lieu mais pas seulement).

By Gee Sur son blog

Mon problème avec les smartphones

Au départ, c’est tout bête : un téléphone vieillissant mal et la volonté d’en changer. Sauf que les smartphones, outre leurs avantages (oui parce que si j’en ai un, ça reste un choix), m’ont toujours dérangé pour plusieurs choses :

• ils sont chers (je n’ai jamais été très à l’aise à l’idée de me trimbaler avec des objets de plusieurs centaines d’euros dans la poche ou à la main) ;
• ils sont fragiles et conçus pour durer le moins de temps possible (jusqu’à la sortie du modèle suivant, en gros), obsolescence programmée, tout ça ;
• ils sont ultra-verrouillés. Firefox OS plus ou moins enterré, Ubuntu Touch à peine existant, c’est encore Android (et dérivées) qui se rapproche le plus du libre (c’est dire dans quelle merde on est).

Pour le prix, je m’étais toujours dirigé vers du milieu de gamme en faisant des concessions sur les perfs (je ne joue que très peu et ne regarde pas de vidéos de manière prolongée dessus, ça aide).

Pour le second, malgré tous mes efforts pour en prendre soin et pour ne conserver un système stable dans le temps, je n’ai jamais réussi à garder un smartphone bien longtemps. Le dernier en date (Sony Xperia J) va avoir 3 ans et honnêtement, il a déjà des soucis depuis facilement 1 an, c’est justement par pragmatisme que je l’ai gardé. Vous allez me dire, j’aurais pu mettre plus cher et avoir un truc plus solide. M’enfin ma sœur a réussi à péter un Samsung à 500€ avec une Chupa Chups, alors vous m’excuserez si je suis sceptique.

Pour le troisième point, il y a la solution de se lancer dans les joyeusetés du root et de l’install de ROM custom. J’ai testé avec CyanogenMod sur mon Xperia, eh bien c’est incroyablement chiant et compliqué (et je dis ça du point de vue d’un mec qui installe des GNU/Linux tous les 4 matins sur des appareils plus ou moins exotiques). Des ROMS hébergées sur d’immondes sites de direct download (avec 1 tiers de liens morts), des forums à inscription obligatoire pour lire les tutos, des utilitaires Windows-only à tous les étages. Yark. Et après on va me dire que Gnunux, c’est trop compliqué.

Le Fairphone

Bref, l’idée de changer de smartphone ne m’enchante pas vraiment. Forcément, j’en viens à chercher des choses comme « smartphone alternatif » sur Internet. C’est comme ça que je retombe sur le Fairphone (dont j’avais déjà entendu parlé d’une oreille distraite avant). Je ne vous refais pas la description, en gros un smartphone qui se veut un peu plus responsable que la moyenne : pas d’exploitation d’enfants pour l’extraction des matières premières, des circuits type commerce équitable, possibilité de facilement réparer et remplacer les pièces du smartphone pour ne pas devoir le jeter au premier souci, etc. Tout de suite, ça me tente bien.

Mais voilà, tout cela a un prix : 525€. Aïe. Bien plus cher que des téléphones aux caractéristiques équivalentes d’autres marques. Rien de surprenant, quand on paie correctement les travailleurs et qu’on essaie d’avoir des pratiques éthiques, on arrive forcément à un prix total plus élevé que des entreprises sans scrupules plus habituées aux filets anti-suicide pour les exploités au bout de la chaîne et du rouleau à la fois. Mais on est bien au-dessus de mon budget habituel. Non pas que je n’en aie pas les moyens, mais comme je l’ai dit, me balader avec des centaines d’euros à la main ou dans la poche, ça m’embête un peu.

Et là je tombe sur le truc qui va faire basculer ma décision : le Fairphone est vendu de base avec un Android classique… mais ils fournissent également une version d’Android Open Source débarrassée de toutes les apps non libres (dont toutes celles de Google, y compris Play Store). Oh. Alors certes, un Android Open Source, ce n’est pas Fairphone qui l’a inventé. Mais là, on parle d’un truc :

• supporté officiellement par le constructeur et prévu pile pour le téléphone en question ;
• qui ne fera donc pas péter la garantie si on l’installe ;
• qui est (visiblement) installable en un clic (hallelujah hare krishna).

Je demande quelques conseils sur Diaspora* et devant les avis majoritairement positifs, je saute le pas. C’est cher, mais après tout j’aurais réglé 2 de mes 3 problèmes avec les smartphones (l’obsolescence et le verrouillage) en faisant une concession sur le troisième (le prix).

Est-ce que ça marche ?

En bref : oui. Premier allumage, je rentre toutes mes infos, je zappe les parties Google et je remplace direct Android par la version open Source fournie par Fairphone. Deuxième allumage, un Android parfaitement fonctionnel sans Google et avec juste ce qu’il faut (applications téléphone, appareil photo, galerie, musique, etc.). Quand on est habitué au merdier que les constructeurs ajoutent habituellement dans leurs Androids personnalisés, c’est presque reposant.

 

Côté matos, rien à redire. On n’est sans doute pas au top de la technologie actuelle, mais pour quelqu’un comme moi habitué à du milieu de gamme, c’est parfait. Je ne vous fais pas la fiche technique, c’est dispo partout sur le web.

L’autonomie (le point qui laisse à désirer dans tous les tests) n’est pas fabuleuse mais rien de catastrophique non plus. En utilisation modérée (un peu de communication, quelques SMS, lire ses mails, ses tweets et ses forums de temps en temps), il peut tenir 2 jours voire 3 en utilisation très modérée. Après si on se lance dans les jeux ou de la navigation un peu intensive, on est plus sur 1 jour, c’est vrai. À part ça, il est stable, fluide, aucun ralentissement, appareil photo très performant (deux exemples ci-dessous). L’écran n’est pas mat mais l’affichage est de très bonne qualité.

#gallery-1 { margin: auto; } #gallery-1 .gallery-item { float: left; margin-top: 10px; text-align: center; width: 50%; } #gallery-1 img { border: 2px solid #cfcfcf; } #gallery-1 .gallery-caption { margin-left: 0; } /* see gallery_shortcode() in wp-includes/media.php */

Après quelques semaines d’utilisation, je m’y sens chez moi. Il y a déjà eu une mise à jour de l’OS depuis que je l’ai installé. Espérons que le support dure.

Android sans Google ?

Cette partie ne concerne pas spécifiquement le Fairphone. Comment on se débrouille avec Android sans compte et sans appli Google ? Comment on se débrouille avec Android quand on veut au maximum utiliser du logiciel libre ?

Déjà, un grand classique que tous les libristes connaissent : F-Droid. C’est un app center alternatif à Google Play Store promu par la Free Software Foundation Europe. Parfait pour n’installer que des applications alternatives et libres. Le logiciel n’est pas des plus sexy (pas de doute, on est bien chez la FSF 🙂 ) mais il fait le boulot très bien. Le plus gros manque, à mon sens, c’est un système de classement : quand on recherche une app, on voudrait savoir laquelle est la plus appréciée ou la plus téléchargée et ce n’est pas possible. On finit toujours par chercher sur le web « best open source photo gallery app android » par exemple. Dommage. Pour le reste, c’est clair, épuré, on installe/désinstalle en un clic, des messages avertissent si l’appli est partiellement non-libre ou promeut des services non-libres, etc. Bref, F-Droid, c’est la supérette bio d’Android.

Ensuite, eh bien il faut juste trouver les applis qui vous conviennent. Le site Droid Break est très bien et donne quelques alternatives à des applications connues.

Un aperçu des applications installées sur mon téléphone :

#gallery-2 { margin: auto; } #gallery-2 .gallery-item { float: left; margin-top: 10px; text-align: center; width: 50%; } #gallery-2 img { border: 2px solid #cfcfcf; } #gallery-2 .gallery-caption { margin-left: 0; } /* see gallery_shortcode() in wp-includes/media.php */

Bien sûr, dans le tas, il y a des applis pour se connecter à des services non-libres (Twitter, YouTube, etc.). Mais contrairement aux applis officielles, elles ont tendance à vous demander sacrément moins d’autorisations, c’est déjà un plus. En vrac :

• TTRSS-Reader : lecteur de flux RSS spécialisé pour Tiny Tiny RSS (branché dans mon cas sur mon compte Framanews) ;
• Diaspora : branché sur mon compte Framasphère. Dispensable puisque la version web de Diaspora* est très satisfaisante ;
• Twidere : appli alternative pour gérer ses comptes Twitter. Pas de publications promotionnelles, pas de timeline et tout marche bien (manque les sondages pour l’instant). Rien à redire ;
• LeafPic : galerie photo bien foutue (je n’étais pas très satisfait de la galerie de base) ;
• Firefox : inutile de le présenter mais le panda roux / renard de feu (choisissez votre camp, perso j’en ai rien à carrer) marche bien aussi sur mobile ;
• K-9 Mail : excellente appli pour gérer des comptes mails multiples. Les fans de Dr Who apprécieront la référence (perso je n’en ai – encore une fois – rien à carrer) ;
• GBCoid : émulateur de GameBoy qui marche très bien et qui est très configurable. Oui, je disais que je ne jouais pas sur smartphone, mais c’est à moitié vrai. Disons que je suis plutôt retrogaming, ce qui se satisfait de perfs modestes en général. Les boutons émulés sur l’écran tactile, faut s’y faire (surtout pour les jeux d’adresse) mais c’est sympa d’avoir un téléphone qui fait GameBoy ;
• ScummVM : pour faire tourner les point’n’click des années 90 (particulièrement ceux de LucasArts) dont je suis un fan absolu. Je viens tout juste de me refaire tout Monkey Island 2 (et là je refais le un, OUI C’EST DANS LE DÉSORDRE ET ALORS) ;
• NewPipe : lecteur pour YouTube. Simple et efficace ;
• Wikipédia : rien à redire, ça marche nickel. J’aime particulièrement le fait que cliquer sur un lien interne ouvre un petit onglet de prévisualisation en bas au lieu d’ouvrir l’article directement ;
• Barcode Scanner : lecteur de QR-Code et assimilés. Le genre d’appli que j’utilise toutes les morts d’évêques mais qu’il est bien pratique d’avoir quand même ;
• Turbo Editor : éditeur de texte. Je n’en ai pas une grande utilisation (éditer du texte sur un smartphone, faut être motivé), mais ça dépanne bien ;
• Tomdroid : gestionnaire de notes. Bien pour relever les compteurs, noter un numéro, etc. Les linuxiens reconnaîtront Tomboy ;
• OsmAnd~ : cartes et navigation basé sur OpenStreetMap avec stockage des cartes en local. Une très bonne appli qui mériterait d’être plus connue, parfaite pour remplacer Google Maps ;
• ShoLi : gestionnaire de liste de courses. C’est tout con mais c’est très pratique (on prépare une liste puis on coche les éléments en tapotant dessus) et je m’en sers tout le temps ;
• DAVdroid : pour gérer les contacts et calendrier de mon compte Owncloud (sur Framadrive) ;
• RedReader : pour gérer un compte Reddit ;
• ownCloud : client OwnCloud (pour la partie fichiers donc), branché aussi sur mon Framadrive ;
• Amaze : l’appli est installée de base, c’est un bon explorateur de fichiers.

Et la petite appli « L’espace client » dont je n’ai pas parlé ? Eh bien là, c’est la solution de secours en l’absence d’alternative : utiliser un marque-page Firefox et en faire une icône. Là, il s’agit du portail web mobile de ma banque. Ils fournissent une appli non-libre sur le Play Store et c’est typiquement le genre de d’appli que, pour des raisons de sécurité, je n’irai pas télécharger en APK directement sur n’importe quel site venu. Bref, le web mobile, c’est bien, ça marche (quand c’est fait correctement).

Comme ça a tendance à manquer un peu, quelques captures d’écran de la plupart de ces applis :

#gallery-3 { margin: auto; } #gallery-3 .gallery-item { float: left; margin-top: 10px; text-align: center; width: 33%; } #gallery-3 img { border: 2px solid #cfcfcf; } #gallery-3 .gallery-caption { margin-left: 0; } /* see gallery_shortcode() in wp-includes/media.php */

Bilan

Alors, est-ce qu’au final, Android sans les applis fermées et sans Google, c’est faisable ? Bien sûr ! Et ça marche même très bien.

Mais est-ce que c’est pareil ? Aussi facile à utiliser ? Aussi pratique ? Alors là, je vais être un peu abrupt : la réponse est non.

Mais au bout d’un moment, il va falloir faire le deuil de ce genre de problématique. Aucune alternative libre n’a la puissance de frappe d’un GAFAM, il est illusoire d’espérer en obtenir la même chose. J’ai parlé de F-Droid comme de la supérette bio d’Android, et ce n’est pas un hasard : je pense que le choix du Libre en informatique, c’est comme le choix du bio en nourriture. Quand tu décides de manger bio, tu sais que les KitKats c’est terminé, tu sais que tes légumes seront peut-être moins brillants et que tu auras moins de choix en prenant des produits locaux (normal, on ne produit pas des bananes n’importe où et à n’importe quel moment de l’année). Mais tu manges bio parce que, quelque part, tu es prêt à faire des concession pour avoir accès à des choses plus saines et que tu sais qu’au final, tu restes « gagnant » par rapport à la bouffe industrielle. Et jamais tu n’exigeras autant de choix et de flexibilité à ta supérette bio qu’au Géant Casino d’à côté.

Le Libre, c’est pareil. Non, je n’aurai pas la dernière appli qui défonce tout, oui je me prive de certaines fonctionnalités hyper-pratiques (Google Maps et Waze pour t’aider à éviter les bouchons quand t’habites près de Nice, c’est un bonheur pourtant). Mais ça vaut le coup. Avoir un téléphone qui vous fout la paix, qui ne vous espionne pas. Des applis qui demandent juste les autorisations qu’il leur faut (c’est-à-dire souvent pas grand-chose). Pas de pub, pas de fonctionnalités payantes cachées, pas de connexion centralisée avec Google, Facebook ou qui sais-je encore. Juste des applis simples qui font le boulot et qui manquent parfois un peu de polish.

On ne démantèlera pas Géant Casino ou Carrefour avec nos petites paluches. Mais, supérette bio après supérette bio, on participe à une alternative de plus en plus viable. C’est pareil pour GAFAM et les petites alternatives qui ne paient pas de mine.

Et comme indiqué au-dessus, ça n’implique pas nécessairement de se couper totalement des services non-libres (type Twitter) dont on reste parfois encore dépendants (je n’ai pas la prétention d’être blanc comme neige sur ce point, je fais comme la plupart des gens : au mieux).

Je conclurais bien en disant que ça me rappelle un certain projet de dégooglisation, mais zut, on va encore dire que je fais de la promo pour les copains 🙂

 

Pour aller plus loin

• Grise Bouille, le BD-blog (et pas que) de Gee
• Le site du Fairphone
• F-Droid, la plateforme d’applications Android Libre
• Droid-Break [EN], pour trouver des applications alternatives.

Le chiffrement, s’il n’est pas encore dans tous nos usages — et loin s’en faut, chez la plupart des utilisateurs, est nettement devenu un argument marketing et une priorité pour les entreprises qui distribuent logiciels et services. En effet, le grand public est beaucoup plus sensible désormais à l’argument de la sécurité de la vie privée. Donc les services qui permettent la communication en ligne rivalisent d’annonces pour promettre et garantir une sécurité toujours plus grande et que l’on puisse activer d’un simple clic.

Que faut-il croire, à qui et quoi pouvons-nous confier nos communications ?

L’article de Hannes Hauswedell que nous avons traduit nous aide à faire un tri salutaire entre les solutions logicielles du marché, pointe les faux-semblants et les failles, puis nous conduit tranquillement à envisager des solutions fédérées et pair à pair reposant sur des logiciels libres. Des réseaux de confiance en somme, ce qui est proche de l’esprit de l’initiative C.H.A.T.O.N.S portée par Framasoft et qui suscite déjà un intérêt grandissant.

Comme d’habitude les commentaires sont ouverts et libres si vous souhaitez par exemple ajouter vos découvertes à ce recensement critique forcément incomplet.

 

Préserver sa vie privée, au-delà du chiffrement

par Hannes Hauswedell

d’après l’article publié sur son blog : Why Privacy is more than Crypto

Traduction Framalang : egilli, Lumi, goofy, roptat, lyn, tchevalier, touriste, Edgar Lori, Penguin

Au cours de l’année dernière on a pu croire que les poules avaient des dents quand les grandes entreprises hégémoniques comme Apple, Google et Facebook ont toutes mis en œuvre le chiffrement à un degré ou un autre. Pour Facebook avec WhatsApp et Google avec Allo, le chiffrement de la messagerie a même été implémenté par rien moins que le célèbre Moxie Marlinspike, un hacker anarchiste qui a la bénédiction d’Edward Snowden !
Donc tout est pour le mieux sur le front de la défense de la vie privée !… Euh, vraiment ?

Sommaire

1. Le chiffrement
2. Logiciels libres et intégrité des appareils
3. Décentralisation, contrôle par les distributeurs et métadonnées
4. En deux mots (pour les moins courageux)

J’ai déjà développé mon point de vue sur la sécurité de la messagerie mobile et j’en ai parlé dans un podcast (en allemand). Mais j’ai pensé qu’il fallait que j’y revienne, car il existe une certaine confusion sur ce que signifient sécurité et confidentialité (en général, mais particulièrement dans le contexte de la messagerie), et parce que les récentes annonces dans ce domaine ne donnent selon moi qu’un sentiment illusoire de sécurité.

Je vais parler de WhatsApp et de Facebook Messenger (tous deux propriétés de Facebook), de Skype (possédé par Microsoft), de Telegram, de Signal (Open Whisper systems), Threema (Threema GmbH), Allo (possédé par Google) et de quelques clients XMPP, je dirai aussi un mot de ToX et Briar. Je n’aborderai pas les diverses fonctionnalités mêmes si elles sont liées à la confidentialité, comme les notifications évidemment mal conçues du type « le message a été lu ». Je n’aborderai pas non plus les questions d’anonymat qui sont connexes, mais selon moi moins importantes lorsqu’il s’agit d’applis de substitution aux SMS, puisque vous connaissez vos contacts de toutes façons.

Le chiffrement

Quand on parle de confidentialité ou de sécurité des communications dans les messageries, il s’agit souvent de chiffrement ou, plus précisément, du chiffrement des données qui se déplacent, de la protection de vos messages pendant qu’ils voyagent vers vos contacts.

Il existe trois moyens classiques pour faire cela :

1. pas de chiffrement : tout le monde sur votre réseau WIFI local ou un administrateur système quelconque du réseau internet peut lire vos données
2. le chiffrement en transit : la connexion au et à partir du fournisseur de service, par exemple les serveurs WhatsApp, et entre les fournisseurs de services est sécurisée, mais le fournisseur de service peut lire le message
3. le chiffrement de bout en bout : le message est lisible uniquement par ceux à qui la conversation est adressée, mais le moment de la communication et les participants sont connus du fournisseur de service

Il y a aussi une propriété appelée « confidentialité persistante » (perfect forward secrecy en anglais) qui assure que les communications passées ne peuvent être déchiffrées, même si la clef à long terme est révélée ou volée.

À l’époque, la plupart des applications, même WhatsApp, appartenaient à la première catégorie. Mais aujourd’hui presque toutes les applications sont au moins dans la deuxième. La probabilité d’un espionnage insoupçonné en est réduite (c’est toujours possible pour les courriels par exemple), mais ce n’est évidemment pas suffisant, puisque le fournisseur de service peut être malveillant ou forcé de coopérer avec des gouvernements malveillants ou des agences d’espionnage sans contrôle démocratique.

C’est pour cela que vous voulez que votre messagerie fasse du chiffrement de bout en bout. Actuellement, les messageries suivantes le font (classées par taille supposée) : WhatsApp, Signal, Threema, les clients XMPP avec GPG/OTR/Omemo (ChatSecure, Conversations, Kontalk).

Les messageries qui disposent d’un mode spécifique (« chat secret » ou « mode incognito ») sont Telegram et Google Allo. Il est vraiment dommage qu’il ne soit pas activé par défaut, donc je ne vous les recommande pas. Si vous devez utiliser l’un de ces programmes, assurez-vous toujours d’avoir sélectionné le mode privé. Il est à noter que les experts considèrent que le chiffrement de bout en bout de Telegram est moins robuste, même s’ils s’accordent à dire que les attaques concrètes pour récupérer le texte d’un message ne sont pas envisageables.

D’autres programmes populaires, comme la messagerie de Facebook ou Skype n’utilisent pas de chiffrement de bout en bout, et devraient être évités. Il a été prouvé que Skype analyse vos messages, je ne m’attarderai donc pas sur ces deux-là.

Logiciels libres et intégrité des appareils

Donc maintenant, les données sont en sécurité tant qu’elles voyagent de vous à votre ami. Mais qu’en est-il avant et après leur envoi ? Ne pouvez-vous pas aussi tenter d’espionner le téléphone de l’expéditeur ou du destinataire avant qu’elles ne soient envoyées et après leur réception ? Oui c’est possible et en Allemagne le gouvernement a déjà activement utilisé la « Quellen-Telekommunikationsüberwachung » (surveillance des communications à la source) précisément pour passer outre le chiffrement.

Revenons à la distinction entre (2) et (3). La différence principale entre le chiffrement en transit et de bout en bout est que vous n’avez plus besoin de faire confiance au fournisseur de service… FAUX : Dans presque tous les cas, la personne qui fait tourner le serveur est la même que celle qui fournit le programme. Donc forcément, vous devez croire que le logiciel fait bien ce qu’il dit faire. Ou plutôt, il doit y avoir des moyens sociaux et techniques qui vous donnent suffisamment de certitude que le logiciel est digne de confiance. Sinon, la valeur ajoutée du chiffrement de bout en bout est bien maigre.

La liberté des logiciels

C’est maintenant que le logiciel libre entre en jeu. Si le code source est publié, il y aura un grand nombre de hackers et de volontaires pour vérifier que le programme chiffre vraiment le contenu. Bien que ce contrôle public ne puisse vous donner une sécurité parfaite, ce processus est largement reconnu comme étant le meilleur pour assurer qu’un programme est globalement sûr et que les problèmes de sécurité sont découverts (et aussi corrigés). Le logiciel libre permet aussi de créer des versions non officielles ou rivales de l’application de messagerie, qui seront compatibles. S’il y a certaines choses que vous n’aimez pas ou auxquelles vous ne faites pas confiance dans l’application officielle, vous pourrez alors toujours en choisir une autre et continuer de chatter avec vos amis.

Certaines compagnies comme Threema qui ne fournissent pas leurs sources assurent évidemment qu’elles ne sont pas nécessaires pour avoir confiance. Elles affirment que leur code a été audité par une autre compagnie (qu’ils ont généralement payée pour cela), mais si vous ne faites pas confiance à la première, pourquoi faire confiance à une autre engagée par celle-ci ? Plus important, comment savoir que la version vérifiée par le tiers est bien la même version que celle installée sur votre téléphone ? (Vous recevez des mises à jours régulières ou non ?)

Cela vaut aussi pour les gouvernements et les entités publiques qui font ce genre d’audits. En fonction de votre modèle de menace ou de vos suppositions sur la société, vous pourriez être enclins à faire confiance aux institutions publiques plus qu’aux institutions privées (ou inversement), mais si vous regardez vers l’Allemagne par exemple, avec le TÜV il n’y a en fait qu’une seule organisation vérificatrice, que ce soit sur la valeur de confiance des applications de messagerie ou concernant la quantité de pollution émise par les voitures. Et nous savons bien à quoi cela a mené !

La confiance

Quand vous décidez si vous faites confiance à un tiers, vous devez donc prendre en compte :

• la bienveillance : le tiers ne veut pas compromettre votre vie privée et/ou il est lui-même concerné
• la compétence : le tiers est techniquement capable de protéger votre vie privée et d’identifier et de corriger les problèmes
• l’intégrité : le tiers ne peut pas être acheté, corrompu ou infiltré par des services secrets ou d’autres tiers malveillants

Après les révélations de Snowden, il est évident que le public est le seul tiers qui peut remplir collectivement ces prérequis ; donc la mise à disposition publique du code source est cruciale. Cela écarte d’emblée WhatsApp, Google Allo et Threema.

« Attendez une minute… mais n’existe-t-il aucun autre moyen de vérifier que les données qui transitent sont bien chiffrées ? » Ah, bien sûr qu’il en existe, comme Threema le fera remarquer, ou d’autres personnes pour WhatsApp. Mais l’aspect important, c’est que le fournisseur de service contrôle l’application sur votre appareil, et peut intercepter les messages avant le chiffrement ou après le déchiffrement, ou simplement « voler » vos clés de chiffrement. « Je ne crois pas que X fasse une chose pareille. » Gardez bien à l’esprit que, même si vous faites confiance à Facebook ou Google (et vous ne devriez pas), pouvez-vous vraiment leur faire confiance pour ne pas obéir à des décisions de justice ? Si oui, alors pourquoi vouliez-vous du chiffrement de bout en bout ? « Quelqu’un s’en apercevrait, non ? » Difficile à dire ; s’ils le faisaient tout le temps, vous pourriez être capable de vous en apercevoir en analysant l’application. Mais peut-être qu’ils font simplement ceci :

si (listeDeSuspects.contient(utilisateurID))
 envoyerClefSecreteAuServeur() ;

Alors seules quelques personnes sont affectées, et le comportement ne se manifeste jamais dans des « conditions de laboratoire ». Ou bien la génération de votre clé est trafiquée, de sorte qu’elle soit moins aléatoire, ou qu’elle adopte une forme plus facile à pirater. Il existe plusieurs approches, et la plupart peuvent facilement être déployées dans une mise à jour ultérieure, ou cachée parmi d’autres fonctionnalités. Notez bien également qu’il est assez facile de se retrouver dans la liste de suspects, car le règlement actuel de la NSA assure de pouvoir y ajouter plus de 25 000 personnes pour chaque suspect « originel ».

À la lumière de ces informations, on comprend qu’il est très regrettable que Open Whisper Systems et Moxie Marlinspike (le célèbre auteur de Signal, mentionné précédemment) fassent publiquement les louanges de Facebook et de Google, augmentant ainsi la confiance en leurs applications [bien qu’il ne soit pas mauvais en soi qu’ils aient aidé à mettre en place le chiffrement, bien sûr]. Je suis assez confiant pour dire qu’ils ne peuvent pas exclure un des scénarios précédents, car ils n’ont pas vu le code source complet des applications, et ne savent pas non plus ce que vont contenir les mises à jour à l’avenir – et nous ne voudrions de toutes façons pas dépendre d’eux pour nous en assurer !

La messagerie Signal

« OK, j’ai compris. Je vais utiliser des logiciels libres et open source. Comme le Signal d’origine ». C’est là que ça se complique. Bien que le code source du logiciel client Signal soit libre/ouvert, il dépend d’autres composants non libres/fermés/propriétaires pour fonctionner. Ces composants ne sont pas essentiels au fonctionnement, mais ils (a) fournissent des métadonnées à Google (plus de détails sur les métadonnées plus loin) et (b) compromettent l’intégrité de votre appareil.

Le dernier point signifie que si même une petite partie de votre application n’est pas digne de confiance, alors le reste ne l’est pas non plus. C’est encore plus critique pour les composants qui ont des privilèges système, puisqu’ils peuvent faire tout et n’importe quoi sur votre téléphone. Et il est particulièrement impossible de faire confiance à ces composants non libres qui communiquent régulièrement des données à d’autres ordinateurs, comme ces services Google. Certes, il est vrai que ces composants sont déjà inclus dans la plupart des téléphones Android dans le monde, et il est aussi vrai qu’il y a très peu d’appareils qui fonctionnent vraiment sans aucun composant non libre, donc de mon point de vue, ce n’est pas problématique en soi de les utiliser quand ils sont disponibles. Mais rendre leur utilisation obligatoire implique d’exclure les personnes qui ont besoin d’un niveau de sécurité supérieur (même s’ils sont disponibles !) ; ou qui utilisent des versions alternatives plus sécurisées d’Android, comme CopperheadOS ; ou simplement qui ont un téléphone sans ces services Google (très courant dans les pays en voie de développement). Au final, Signal créé un « effet réseau » qui dissuade d’améliorer la confiance globale d’un appareil mobile, parce qu’il punit les utilisateurs qui le font. Cela discrédite beaucoup de promesses faites par ses auteurs.

Et voici le pire : Open Whisper Systems, non seulement, ne supporte pas les systèmes complètements libres, mais a également menacé de prendre des mesures légales afin d’empêcher les développeurs indépendants de proposer une version modifiée de l’application client Signal qui fonctionnerait sans les composants propriétaires de Google et pourrait toujours interagir avec les autres utilisateurs de Signal ([1] [2] [3]). À cause de cela, des projets indépendants comme LibreSignal sont actuellement bloqués. En contradiction avec leur licence libre, ils s’opposent à tout client du réseau qu’ils ne distribuent pas. De ce point de vue, l’application Signal est moins utilisable et moins fiable que par exemple Telegram qui encourage les clients indépendants à utiliser leurs serveurs et qui propose des versions entièrement libres.

Juste pour que je ne donne pas de mauvaise impression : je ne crois pas qu’il y ait une sorte de conspiration entre Google et Moxie Marlinspike, et je les remercie de mettre au clair leur position de manière amicale (au moins dans leur dernière déclaration), mais je pense que la protection agressive de leur marque et leur insistance à contrôler tous les logiciels clients de leur réseau met à mal la lutte globale pour des communications fiables.

Décentralisation, contrôle par les distributeurs et métadonnées

Un aspect important d’un réseau de communication est sa topologie, c’est-à-dire la façon dont le réseau est structuré. Comme le montre l’image ci-dessous, il y a plusieurs approches, toutes (plus ou moins) largement répandues. La section précédente concernait ce qui se passe sur votre téléphone, alors que celle-ci traite de ce qui se passe sur les serveurs, et du rôle qu’ils jouent. Il est important de noter que, même dans des réseaux centralisés, certaines communications ont lieu en pair-à-pair (c’est-à-dire sans passer par le centre) ; mais ce qui fait la différence, c’est qu’il nécessitent des serveurs centraux pour fonctionner.

Réseaux centralisés

Les réseaux centralisés sont les plus courants : toutes les applications mentionnées plus haut (WhatsApp, Telegram, Signal, Threema, Allo) reposent sur des réseaux centralisés. Bien que beaucoup de services Internet ont été décentralisés dans le passé, comme l’e-mail ou le World Wide Web, beaucoup de services centralisés ont vu le jour ces dernières années. On peut dire, par exemple, que Facebook est un service centralisé construit sur la structure WWW, à l’origine décentralisée.

Les réseaux centralisés font souvent partie d’une marque ou d’un produit plus global, présenté comme une seule solution (au problème des SMS, dans notre cas). Pour les entreprises qui vendent ou qui offrent ces solutions, cela présente l’avantage d’avoir un contrôle total sur le système, et de pouvoir le changer assez rapidement, pour offrir (ou imposer) de nouvelles fonctionnalités à tous les utilisateurs.

Même si l’on suppose que le service fournit un chiffrement de bout en bout, et même s’il existe une application cliente en logiciel libre, il reste toujours les problèmes suivants :

métadonnées : le contenu de vos messages est chiffré, mais l’information qui/quand/où est toujours accessible pour votre fournisseur de service
déni de service : le fournisseur de service ou votre gouvernement peuvent bloquer votre accès au service

Il y a également ce problème plus général : un service centralisé, géré par un fournisseur privé, peut décider quelles fonctionnalités ajouter, indépendamment du fait que ses utilisateurs les considèrent vraiment comme des fonctionnalités ou des « anti-fonctionnalités », par exemple en indiquant aux autres utilisateurs si vous êtes « en ligne » ou non. Certaines de ces fonctionnalités peuvent être supprimées de l’application sur votre téléphone si c’est du logiciel libre, mais d’autres sont liées à la structure centralisée. J’écrirai peut-être un jour un autre article sur ce sujet.

Métadonnées

Comme expliqué précédemment, les métadonnées sont toutes les données qui ne sont pas le message. On pourrait croire que ce ne sont pas des données importantes, mais de récentes études montrent l’inverse. Voici des exemples de ce qu’incluent les métadonnées : quand vous êtes en ligne, si votre téléphone a un accès internet, la date et l’heure d’envoi des messages et avec qui vous communiquez, une estimation grossière de la taille du message, votre adresse IP qui peut révéler assez précisément où vous vous trouvez (au travail, à la maison, hors de la ville, et cætera), éventuellement aussi des informations liées à la sécurité de votre appareil (le système d’exploitation, le modèle…). Ces informations sont une grande menace contre votre vie privée et les services secrets américains les utilisent réellement pour justifier des meurtres ciblés (voir ci-dessus).

La quantité de métadonnées qu’un service centralisé peut voir dépend de leur implémentation précise. Par exemple, les discussions de groupe avec Signal et probablement Threema sont implémentées dans le client, donc en théorie le serveur n’est pas au courant. Cependant, le serveur a l’horodatage de vos communications et peut probablement les corréler. De nouveau, il est important de noter que si le fournisseur de service n’enregistre pas ces informations par défaut (certaines informations doivent être préservées, d’autres peuvent être supprimées immédiatement), il peut être forcé à enregistrer plus de données par des agences de renseignement. Signal (comme nous l’avons vu) ne fonctionne qu’avec des composants non-libres de Google ou Apple qui ont alors toujours une part de vos métadonnées, en particulier votre adresse IP (et donc votre position géographique) et la date à laquelle vous avez reçu des messages.

Pour plus d’informations sur les métadonnées, regardez ici ou là.

Déni de service

Un autre inconvénient majeur des services centralisés est qu’ils peuvent décider de ne pas vous servir du tout s’ils le veulent ou qu’ils y sont contraints par la loi. Comme nombre de services demandent votre numéro lors de l’enregistrement et sont opérés depuis les États-Unis, ils peuvent vous refuser le service si vous êtes cubain par exemple. C’est particulièrement important puisqu’on parle de chiffrement qui est grandement régulé aux États-Unis.

L’Allemagne vient d’introduire une nouvelle loi antiterroriste dont une partie oblige à décliner son identité lors de l’achat d’une carte SIM, même prépayée. Bien que l’hypothèse soit peu probable, cela permettrait d’établir une liste noire de personnes et de faire pression sur les entreprises pour les exclure du service.

Plutôt que de travailler en coopération avec les entreprises, un gouvernement mal intentionné peut bien sûr aussi cibler le service directement. Les services opérés depuis quelques serveurs centraux sont bien plus vulnérables à des blocages nationaux. C’est ce qui s’est passé pour Signal et Telegram en Chine.

Réseaux déconnectés

Lorsque le code source du serveur est libre, vous pouvez monter votre propre service si vous n’avez pas confiance dans le fournisseur. Ça ressemble à un gros avantage, et Moxie Marlinspike le défend ainsi :

Avant vous pouviez changer d’hébergeur, ou même décider d’utiliser votre propre serveur, maintenant les utilisateurs changent simplement de réseau complet. […] Si un fournisseur centralisé avec une infrastructure ouverte modifiait affreusement ses conditions, ceux qui ne seraient pas d’accord ont le logiciel qu’il faut pour utiliser leur propre alternative à la place.

Et bien sûr, c’est toujours mieux que de ne pas avoir le choix, mais la valeur intrinsèque d’un réseau « social » vient des gens qui l’utilisent et ce n’est pas évident de changer si vous perdez le lien avec vos amis. C’est pour cela que les alternatives à Facebook ont tant de mal. Mme si elles étaient meilleures sur tous les aspects, elles n’ont pas vos amis.

Certes, c’est plus simple pour les applications mobiles qui identifient les gens via leur numéro, parce qu’au moins vous pouvez trouver vos amis rapidement sur un nouveau réseau, mais pour toutes les personnes non techniciennes, c’est très perturbant d’avoir 5 applications différentes juste pour rester en contact avec la plupart de ses amis, donc changer de réseau ne devrait qu’être un dernier recours.

Notez qu’OpenWhisperSystems se réclame de cette catégorie, mais en fait ils ne publient que des parties du code du serveur de Signal, de sorte que vous ne soyez pas capables de monter un serveur avec les mêmes fonctionnalités (plus précisément la partie téléphonie manque).

La fédération

La fédération est un concept qui résout le problème mentionné plus haut en permettant en plus aux fournisseurs de service de communiquer entre eux. Donc vous pouvez changer de fournisseur, et peut-être même d’application, tout en continuant à communiquer avec les personnes enregistrées sur votre ancien serveur. L’e-mail est un exemple typique d’un système fédéré : peu importe que vous soyez tom@gmail.com ou jeanne@yahoo.com ou même linda@serveur-dans-ma-cave.com, tout le monde peut parler avec tout le monde. Imaginez combien cela serait ridicule, si vous ne pouviez communiquer qu’avec les personnes qui utilisent le même fournisseur que vous ?

L’inconvénient, pour un développeur et/ou une entreprise, c’est de devoir définir publiquement les protocoles de communication, et comme le processus de standardisation peut être compliqué et très long, vous avez moins de flexibilité pour modifier le système. Je reconnais qu’il devient plus difficile de rendre les bonnes fonctionnalités rapidement disponibles pour la plupart des gens, mais comme je l’ai dit plus haut, je pense que, d’un point de vue de la vie privée et de la sécurité, c’est vraiment une fonctionnalité, car plus de gens sont impliqués et plus cela diminue la possibilité pour le fournisseur d’imposer des fonctionnalités non souhaitées aux utilisateurs ; mais surtout car cela fait disparaître « l’effet d’enfermement ». Cerise sur le gâteau, ce type de réseau produit rapidement plusieurs implémentations du logiciel, à la fois pour l’application utilisateur et pour le logiciel serveur. Cela rend le système plus robuste face aux attaques et garantit que les failles ou les bugs présents dans un logiciel n’affectent pas le système dans son ensemble.

Et, bien sûr, comme évoqué précédemment, les métadonnées sont réparties entre plusieurs fournisseurs (ce qui rend plus difficile de tracer tous les utilisateurs à la fois), et vous pouvez choisir lequel aura les vôtres, voire mettre en place votre propre serveur. De plus, il devient très difficile de bloquer tous les fournisseurs, et vous pouvez en changer si l’un d’entre eux vous rejette (voir « Déni de service » ci-dessus).

Une remarque au passage : il faut bien préciser que la fédération n’impose pas que des métadonnées soient vues par votre fournisseur d’accès et celui de votre pair. Dans le cas de la messagerie électronique, cela représente beaucoup, mais ce n’est pas une nécessité pour la fédération par elle-même, c’est-à-dire qu’une structure fédérée bien conçue peut éviter de partager les métadonnées dans les échanges entre fournisseurs d’accès, si l’on excepte le fait qu’il existe un compte utilisateur avec un certain identifiant sur le serveur.

Alors est-ce qu’il existe un système identique pour la messagerie instantanée et les SMS ? Oui, ça existe, et ça s’appelle XMPP. Alors qu’initialement ce protocole n’incluait pas de chiffrement fort, maintenant on y trouve un chiffrement du même niveau de sécurité que pour Signal. Il existe aussi de très bonnes applications pour mobile sous Android (« Conversations ») et sous iOS (« ChatSecure »), et pour d’autres plateformes dans le monde également.

Inconvénients ? Comme pour la messagerie électronique, il faut d’abord vous enregistrer pour créer un compte quelque part et il n’existe aucune association automatique avec les numéros de téléphone, vous devez donc convaincre vos amis d’utiliser ce chouette nouveau programme, mais aussi trouver quels fournisseur d’accès et nom d’utilisateur ils ont choisis. L’absence de lien avec le numéro de téléphone peut être considérée par certains comme une fonctionnalité intéressante, mais pour remplacer les SMS ça ne fait pas l’affaire.

La solution : Kontalk, un client de messagerie qui repose sur XMPP et qui automatise les contacts via votre carnet d’adresses. Malheureusement, cette application n’est pas encore aussi avancée que d’autres mentionnées plus haut. Par exemple, il lui manque la gestion des groupes de discussion et la compatibilité avec iOS. Mais Kontalk est une preuve tangible qu’il est possible d’avoir avec XMPP les mêmes fonctionnalités que l’on trouve avec WhatsApp ou Telegram. Selon moi, donc, ce n’est qu’une question de temps avant que ces solutions fédérées ne soient au même niveau et d’une ergonomie équivalente. Certains partagent ce point de vue, d’autres non.

Réseaux pair à pair

Les réseaux pair à pair éliminent complètement le serveur et par conséquent toute concentration centralisée de métadonnées. Ce type de réseaux est sans égal en termes de liberté et il est pratiquement impossible à bloquer par une autorité. ToX est un exemple d’application pair à pair, ou encore Ricochet (pas pour mobile cependant), et il existe aussi Briar qui est encore en cours de développement, mais ajoute l’anonymat, de sorte que même votre pair ne connaît pas votre adresse IP. Malheureusement il existe des problèmes de principe liés aux appareils mobiles qui rendent difficile de maintenir les nombreuses connexions que demandent ces réseaux. De plus il semble impossible pour le moment d’associer un numéro de téléphone à un utilisateur, si bien qu’il est impossible d’avoir recours à la détection automatique des contacts.

Je ne crois pas actuellement qu’il soit possible que ce genre d’applications prenne des parts de marché à WhatsApp, mais elles peuvent être utiles dans certains cas, en particulier si vous êtes la cible de la surveillance et/ou membre d’un groupe qui décide collectivement de passer à ces applications pour communiquer, une organisation politique par exemple.

 

En deux mots

• La confidentialité de nos données privées est l’objet d’un intérêt accru et les utilisateurs cherchent activement à se protéger mieux.
• On peut considérer que c’est un bon signe quand les distributeurs principaux de logiciels comprennent qu’ils doivent réagir à cette situation en ajoutant du chiffrement à leurs logiciels ; et qui sait, il est possible que ça complique un peu la tâche de la NSA.
• Toutefois, il n’y a aucune raison de leur faire plus confiance qu’auparavant, puisqu’il n’existe aucun moyen à notre disposition pour savoir ce que font véritablement les applications, et parce qu’il leur reste beaucoup de façons de nous espionner.
• Si en ce moment vous utilisez WhatsApp, Skype, Threema ou Allo et que vous souhaitez avoir une expérience comparable, vous pouvez envisager de passer à Telegram ou Signal. Ils valent mieux que les précédents (pour diverses raisons), mais ils sont loin d’être parfaits, comme je l’ai montré. Nous avons besoin à moyen et long terme d’une fédération.
• Même s’ils nous paraissent des gens sympas et des hackers surdoués, nous ne pouvons faire confiance à OpenWhisperSystemspour nous délivrer de la surveillance, car ils sont aveugles à certains problèmes et pas très ouverts à la coopération avec la communauté.
• Des trucs assez sympas se préparent du côté du XMPP, surveillez Conversations, chatSecure et Kontalk. Si vous le pouvez, soutenez-les avec du code, des dons et des messages amicaux.
• Si vous souhaitez une approche sans aucune métadonnée et/ou anonymat, essayez Tor ou ToX, ou attendez Briar.