Après 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, voici un aperçu tout simple des composants de base d’un logiciel.

Nos lecteurs les plus au courant n’y trouveront rien qu’ils ne sachent déjà, mais l’intérêt de cette présentation c’est justement qu’elle rend abordables et compréhensibles au grand public des objets techniques qui peuvent s’avérer très complexes à comprendre (…et maîtriser !). On peut dire que la démarche choisie ici, pragmatique et imagée, ne manque pas de pédagogie.
Merci à nos lecteurs soucieux des valeurs du libre de noter que l’auteur n’introduit les notions que progressivement : c’est seulement dans quelques chapitres qu’elle établira clairement une distinction claire qui nous est chère.

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 !

De quoi sont faits les logiciels

par Nadia Eghbal

Traduction framalang : Luc, woof, Diane, xi, serici, Lumibd, goofy, alien spoon, flo, salade, AFS, lyn., anthony

Tous les sites web ou les applications mobiles que nous utilisons, même les plus simples, sont constitués de multiples composants plus petits, tout comme un immeuble est fait de briques et de ciment.

Imaginez par exemple que vous désiriez poster une photo sur Facebook. Vous ouvrez votre appli mobile Facebook, ce qui déclenche le logiciel de Facebook pour vous afficher votre fil d’actualités.

Vous téléchargez une photo depuis votre téléphone, ajoutez un commentaire, puis vous cliquez sur « Envoyer ». Une autre partie du logiciel de Facebook, en charge du stockage des données, se souvient de votre identité et poste la photo sur votre profil. Finalement, une troisième partie de ce logiciel prend le message que vous avez saisi sur votre téléphone et le montre à tous vos amis à travers le monde.

Bien que ces opérations aient lieu sur Facebook, en réalité, ce n’est pas Facebook qui a développé toutes les briques nécessaires pour vous permettre de publier sur son application. Ses développeurs ont plutôt utilisé du code libre, public, mis à disposition de tous sur Internet par des bénévoles. Facebook ne publie pas la liste des projets qu’ils utilisent, mais une de ses filiales, Instagram, le fait et remercie certains de ces projets sur sa page d’accueil et dans son application mobile

Utiliser du code public est plus efficace pour des entreprises comme Facebook ou Instagram que de développer à nouveau tous les composants par elles-mêmes. Développer un logiciel est comparable à la construction d’un immeuble. Une entreprise du bâtiment ne produit pas ses marteaux et ses perceuses, et n’ira pas non plus chercher du bois pour découper les troncs en planches.

Elle préférera les acheter à un fournisseur et se fournir en bois auprès d’une scierie pour finir le travail plus rapidement.

Grâce aux licences permissives, les sociétés telles que Facebook ou Instagram ne sont pas obligées de payer pour ce code, mais sont libres d’en profiter grassement. Ce n’est pas différent d’une entreprise de transport (Instagram) qui utilise les infrastructures routières publiques (code public) pour acheminer ses produits à des fins commerciales (application Instagram).

Mike Krieger, un des co-fondateurs d’Instagram, a insisté sur ce point en 2013 et encouragé d’autres entrepreneurs à :

emprunter plutôt que construire à chaque fois que c’est possible. Il existe des centaines d’excellents outils qui peuvent vous faire gagner du temps et vous permettre de véritablement vous concentrer sur le développement de votre produit. (source)

Voici quelques-uns des outils utilisés par une entreprise de logiciels :

Frameworks (environnements de développement)

Les framewoks offrent une base, une sorte d’échafaudage, une structure. Imaginez cela comme un schéma pour toute une application. Comme un plan, un framework définit la manière dont l’application se comportera sur mobile, ou comment ses données seront sauvegardées dans une base de données. Par exemple Rails et Django sont des frameworks.

Langages

Les langages de programmation constituent l’épine dorsale de la communication des logiciels, comme la langue anglaise (NdT : aux USA bien sûr) qu’emploient les ouvriers du bâtiment sur un chantier pour se comprendre. Les langages de programmation permettent aux divers composants du logiciel d’agir et de communiquer entre eux. Si par exemple vous créez un compte sur un site internet et que vous cliquez sur « S’enregistrer », cette application peut utiliser des langages comme le JavaScript ou le Ruby pour sauvegarder vos informations dans une base de données.

Parmi les langages de programmation les plus populaires on peut mentionner le Python, le JavaScript et le C.

Bibliothèques

Les bibliothèques sont des fonctions pré-fabriqués qui accélèrent l’écriture du code d’un logiciel, tout comme une entreprise du bâtiment achète des fenêtres préfabriquées au lieu de les assembler à partir des composants de base. Par exemple, au lieu de développer leur propre système d’identification pour les utilisateurs de leur application, les développeurs et développeuses peuvent utiliser une bibliothèque appelée OAuth. Au lieu d’écrire leur propre code pour visualiser des données sur une page web, ils ou elles peuvent utiliser une bibliothèque appelée d3.

Bases de données

Les bases de données stockent des informations (profils d’utilisateurs, adresses électroniques ou codes de cartes bancaires par exemple) qui peuvent être utilisées par l’application. À chaque fois qu’une application a besoin de se souvenir d’une information qui vous concerne, l’application la stocke dans la base de données. Parmi les systèmes de gestion de bases de données (SGBD) les plus populaires on trouve notamment MySQL et PostgreSQL.

Serveurs web et d’applications

Ces serveurs gèrent certaines requêtes envoyées par les utilisateurs sur Internet : on peut les voir comme des centrales téléphoniques qui répartissent les appels. Par exemple, si vous saisissez une URL dans la barre d’adresse de votre navigateur, un serveur web vous répondra en vous envoyant la page concernée. Si vous envoyez un message à un ami sur Facebook, le message sera d’abord envoyé à un serveur d’applications qui déterminera qui vous essayez de contacter puis transmettra votre message au compte de votre ami.

Parmi les serveurs web très répandus, citons Apache et Nginx.

Certains de ces outils, comme les serveurs et les bases de données, sont coûteux, surtout à l’échelle d’une entreprise, ce qui les rend plus faciles à monétiser. Par exemple, Heroku, une plate-forme sur le cloud (sur un serveur distant) qui fournit des solutions d’hébergement et de bases de données, propose une offre de base gratuite, mais il faut payer pour avoir accès à plus de données ou de bande passante. De grands sites reposent sur Heroku comme ceux de Toyota ou de Macy, et l’entreprise a été rachetée en 2010 par Salesforce.com pour 212 millions de dollars.

Il est plus difficile de faire payer d’autres types d’outils de développement, tel que les frameworks, de nombreuses bibliothèques et langages de programmation, qui sont souvent créés et maintenus par des bénévoles.

Ce type d’outils ressemble plus à des ressources qu’à des services qui peuvent être activés ou désactivés : les rendre payants limiterait fortement leur adoption. C’est pourquoi n’importe qui, que ce soit une entreprise milliardaire ou un adolescent apprenti développeur, peut utiliser gratuitement ces composants pour créer ses propres logiciels.

Par exemple, selon la page d’accueil d’Instagram, l’une des bibliothèques utilisées par l’entreprise est Appirater. Il s’agit d’une bibliothèque qui facilite les fonctions de rappels automatiques pour l’évaluation d’une application, à destination des utilisateurs d’iPhone. Elle a été créée en 2009 par Arash Payan, un développeur indépendant basé à Los Angeles. Le projet n’apporte aucun revenu à Payan.

C’est comme si des scieries, des centrales à béton et des magasins de matériel donnaient leurs matériaux de base à une entreprise du bâtiment, puis continuaient à approvisionner cette entreprise.

José Antonio Rey, membre depuis plusieurs années de la communauté Ubuntu, témoigne de la richesse des échanges dans les communautés open source. Des communautés réunissant des gens que tout pourrait séparer : langue, culture, distance mais qui au contraire se rejoignent autour d’un but commun.

Faire tomber les barrières de la langue et de la distance dans les projets open source

Article original : Open source took me around the world

Par José Antonio Rey

Traduction : Framasky, goofy, audionuma, Brice, AFS

Les communautés open source ont été parmi les premières à utiliser Internet pour s’affranchir de la distance physique entre les personnes. Internet est un outil incroyable, puisqu’il nous permet de collaborer où que l’on soit. Peu importe que vous déjeuniez au pied de la tour Eiffel ou que vous vous réveilliez sous le soleil de San Francisco, Internet a permis de connecter les personnes de manière plus étroite.

J’habite au Pérou, et j’y ai toujours vécu. J’étudie au Pérou, et Internet m’a permis de découvrir des informations précieuses pour mes projets et ma vie en général. Néanmoins, lorsque j’ai rejoint la communauté Linux, ma vie a radicalement changé.

Une nuit, j’avais des problèmes avec mon écran qui ne fonctionnait pas correctement. Je me suis donc connecté à un canal IRC, et quelqu’un en Espagne m’a aidé à résoudre le problème. Ensuite, j’ai pris une décision que je n’ai jamais regrettée : je me suis connecté pour répondre à des questions posées par d’autres utilisateurs de Linux. Je l’ai fait un temps, me concentrant sur les communautés Ubuntu, et on m’a finalement demandé de rédiger un tutoriel pour la communauté. Je n’y connais pas grand chose, ai-je alors pensé, mais j’ai décidé de le faire quand même. J’ai présenté des trucs et astuces concernant l’utilisation du navigateur Firefox. Ma présentation s’est bien déroulée, même si j’étais plutôt nerveux. Cela m’a amené à rencontrer des gens de la communauté, et deux mois plus tard, je m’envolais vers San Francisco pour mon premier sommet des développeurs Ubuntu. Ce fut le premier de mes nombreux voyages.

Rejoindre une communauté Linux m’a permis d’améliorer bon nombre de mes compétences, en anglais par exemple. Ma langue maternelle est l’espagnol, le début de l’apprentissage a donc été difficile. La moitié de mes journées était en espagnol, l’autre en anglais. Tous mes logiciels fonctionnaient en anglais, et j’ai commencé à trouver bizarre de lire des traductions en espagnol. Améliorer mon anglais m’a aussi permis de me sentir un peu plus à l’aise lors de conversations avec d’autres personnes. Je commençais à m’impliquer de plus en plus, et j’ai donc fait la connaissance d’un grand nombre de personnes, des États-Unis, d’Australie, d’Inde, du Royaume-Uni, de Colombie, d’Argentine, d’Uruguay et d’autres pays. Le nombre de personnes que j’ai rencontrées est incroyable, et ne cesse d’augmenter. Bien sûr, le décalage horaire est une vraie plaie quand on travaille avec des gens tout autour du monde, mais c’est largement compensé par les avantages liés au fait de connaître ces gens et de travailler avec eux.

Ce passe-temps me permet de travailler sur de beaux projets qui m’intéressent. Et si j’ai un problème avec un logiciel, je peux le réparer moi-même ! Je n’ai pas besoin d’attendre que quelqu’un m’entende et fasse attention à moi. Encore mieux, j’apprends à utiliser de nouveaux outils en faisant cela. Si je suis bloqué ou si je ne sais pas comment régler un problème, la communauté est là pour me donner un coup de main.

En travaillant avec le Conseil des Communautés Locales d’Ubuntu (Ubuntu Local Communities Council), j’ai rendu service à des communautés partout dans le monde et les ai rendues plus autonomes, dans leurs actions de promotion par exemple. Les différences culturelles sont l’une des choses les plus difficiles à gérer dans un projet. Contrairement à ce que pensent certaines personnes, gérer un projet ce n’est pas seulement superviser les choses, parfois nous avons dû mettre fin à des disputes entre participants ou entre équipes. J’ai alors été frappé par cette caractéristique importante de la participation à une communauté en ligne : nous sommes tous des personnes avec des points de vue différents, et notre compréhension des choses et des problèmes peut varier en fonction de notre culture. Cela n’est pas quelque chose qui doit nous effrayer, mais bien une chose que nous devons comprendre. Cela montre à quel point notre monde est grand, comment Internet et les communautés du Libre peuvent nous rapprocher et quelle diversité règne dans notre communauté.

Grâce à Internet, les communautés open source ont le pouvoir de vous mettre en contact avec d’autres personnes à travers le monde, parfois vous les rencontrerez même dans le monde réel. Il existe plusieurs communautés qui organisent des rencontres de développeurs et des conférences. Et, si vous êtes assez actif, vous serez invité à y participer. En ce qui me concerne, les personnes qui développaient les logiciels voulaient connaître mes contributions, j’ai alors pu voyager tout autour du monde afin de les rencontrer pour en discuter.

En rejoignant une communauté open source, vous ne contribuez pas seulement à un logiciel, vous rejoignez un réseau de personnes disséminées à travers le monde qui rendent ce logiciel réalisable. Vous devrez franchir différentes barrières, et tout particulièrement celle de la langue. Mais je peux vous dire que c’est une des plus valorisantes expériences que vous pourrez vivre. Vous deviendrez meilleur dans des domaines variés, acquerrez de nouvelles compétences, en découvrirez d’autres, et cerise sur le gâteau, vous travaillerez avec une formidable équipe de personnes provenant de tous les coins du monde, toutes unies vers un objectif commun. Une fois que vous aurez rejoint une communauté open source, vous comprendrez comment un groupe de personnes travaillant avec le même but peut faire tomber toutes les barrières, même celle de la distance.

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.

Ce nouvel article issu du blog Grise Bouille nous parle un peu de l’Éducation Nationale et surtout de son Ministère. Où quand le partenariat public/privé va un peu trop loin…

Cette BD est librement inspiré de l’article Cantines scolaires: l’Education Nationale signe un partenariat avec Mac Donald écrit par JCFrog.

Crédit : Simon Gee Giraudot (Creative Commons By-Sa)

Sx est chargé de mission du CECIL (Centre d’Étude sur la Citoyenneté, l’Informatisation et les Libertés) et principal contributeur du contenu du Guide de survie des aventuriers d’Internet (ou comment protéger ses libertés en milieu numérique hostile).

Ce livret de 68 pages A5 est la version papier de 12 fiches pratiques déjà disponibles sur leur site.
Comme il y parle beaucoup de nous, nous voulions savoir pourquoi il nous avait autant à la bonne.

Salut Sx, est-ce que tu peux nous en dire plus sur toi ?

En très bref, j’ai une double formation juridique en droit des techniques de l’information et de la communication et en droit des contrats que je transmets par l’enseignement universitaire, notamment auprès de public de non-juristes. Bidouilleur dès que j’en ai l’occasion, j’aime essayer de toujours mieux comprendre comment fonctionnent les choses et notamment les dynamiques de pouvoir. Depuis ma lecture de l’ouvrage de Lawrence Lessig, « Code and other laws of cyberspace », il y a une bonne dizaine d’années, je fais de la recherche sur les interactions entre les avancées des techniques, notamment informatiques, et les libertés fondamentales dans des approches de défense des libertés et des idéaux démocratiques.

Je me retrouve assez dans l’article 1 de la loi informatique et libertés « L’informatique doit être au service de chaque citoyen. Son développement doit s’opérer dans le cadre de la coopération internationale. Elle ne doit porter atteinte ni à l’identité humaine, ni aux droits de l’homme, ni à la vie privée, ni aux libertés individuelles ou publiques » en me désolant de ses violations quotidiennes.

Et sur le CECIL ? La liste des parrainages est impressionnante !

Le CECIL s’est construit en versant public de deux autres associations de chercheurs travaillant sur les interactions entre TIC et société qui ont désormais fusionné dans l’association « Creis-Terminal ». La liste de parrainage du lancement de l’asso en provient pour partie, mais il s’agit plus largement de personnes qui au moment du lancement du CECIL avaient déjà saisi l’importance de la thématique « Informatique et Libertés » dans le débat public et l’importance de la compréhension publique de ces problématiques.

L’objectif principal du CECIL est de réintroduire le champ Informatique et Libertés dans le débat public, dans celui sur la démocratie et de fournir aux citoyenn·e·s et aux associations les moyens d’orienter les choix technologiques liés à l’informatisation, au fichage et au contrôle social.

En ce sens, en plus d’un regroupement de travaux importants sur la question, on réalise des actions de sensibilisation (ciné / café débat / interventions ponctuelles / tenue de stand), de formation (à tous les niveaux) et d’éducation populaire sur les questions de surveillance, d’usage raisonné des outils du numérique, etc.

L’association a également un versant « lobbying citoyen » dans le cadre de sa participation active au collectif de l’Observatoire des Libertés et du Numérique aux côtés de la Ligue des Droits de l’Homme (qui nous a bien aidé pour la mise en forme et la publication du guide), mais également du Syndicat de la Magistrature, de la Quadrature du Net, du Syndicat des Avocats de France, d’Amnesty International France et du Creis-Terminal.

Le petit Guide que l’on publie est issu d’un besoin interne de disposer d’un outil de formation pour des « ateliers d’autodéfense numérique ». Ces ateliers visent, dans la même optique que les Cafés Vie Privée, à sensibiliser les citoyen·ne·s aux dangers de la surveillance illégitime et les aider à faire les premiers pas pour commencer à reprendre en main leur vie privée dans leurs usages numériques. Notre souhait est aussi qu’il·le·s pèsent par ce biais sur les enjeux politiques connexes.

Le Guide est un bon panorama des apports du libre dans la lutte pour la défense des libertés, mais c’est un domaine où les lignes bougent vite. On imagine qu’il sera tenu à jour ? A quelle fréquence ?

Oui sur tout ce qui touche à la surveillance et à la sécurité, il est autant important de garder ses logiciels que ses pratiques à jour. Les 6 premières fiches ont été publiées en mars 2015 sur le site. Depuis on a continué à les enrichir avec des nouvelles, mais aussi en faisant des mises à jour constantes, aussi bien côté outils et pratiques (uBlock Origin et Qwant par exemple) que pour les références. Cela au fur et à mesure de nos découvertes personnelles et collectives.

Le guide papier est forcément figé et vise surtout à être un support pédagogique, plus engageant qu’un site, pour faire adopter de premières bonnes mesures à qui le souhaite déjà un peu. Effectivement, la « v1 » n’aura probablement plus beaucoup de pertinence dans quelques années, mais espérons que d’ici là ce·lle·ux qui l’auront consulté seront devenus autonomes sur ces questions. Au-delà des outils proposés concrètement, on invite surtout le lecteur à se poser les bonnes questions et à aller plus loin aussi bien dans une approche individuelle que collective dans la défense des libertés sur Internet, et sur ça le guide restera longtemps d’actualité.

En attendant, les fiches présentes sur le site Internet continueront d’être mises à jour régulièrement avec aussi bien de nouvelles (deux fiches sont en préparation pour donner des pistes pour mieux protéger ses données sur ordiphones) que des évolutions des anciennes. On attend par exemple de l’avoir testé un peu plus et d’avoir également des retours plus poussés, mais le nouveau navigateur « Brave » pourrait sûrement trouver sa place dans la première fiche. Les nouveaux services stars de Framasoft, ou encore mieux, des CHATONS également !

À peine lancé, le guide semble trouver son public, donc il est probable (ou du moins je l’espère ! ) qu’on écoule l’intégralité du premier tirage dans les mois à venir. C’est une projection un peu optimiste, mais espérons qu’on arrive à faire la publication d’une version par an (avec qui sait des versions intermédiaires ?) pour garder cet outil à jour et continuer de sensibiliser sur les questions. En résumé, des petits tirages réguliers et mis à jour et surtout toujours plus de sensibilisation en formation directe sur les questions de surveillance publique et privée pour arriver à (attention gros mot) toujours plus d’autodétermination informationnelle de chacun·e !

D’ailleurs, instant promotionnel, la brochure est en vente sur stand au prix de 5 euros, mais si des structures (collèges, lycées, asso…) veulent en acquérir un grand nombre à un prix plus intéressant pour s’en servir comme support pédagogique, qu’elles n’hésitent surtout pas à nous contacter !

Est-ce que vous avez prévu de le mettre sur un Gitlab pour permettre aux internautes de contribuer ?

Est-ce que cette question vise à nous faire remarquer que l’on n’a pas inclus Framagit dans les outils Framasoft présentés ?  Plus sérieusement, non ce n’était pas prévu, on ne s’est pas vraiment posé la question jusque maintenant. On a déjà eu plusieurs retours de personnes qui nous ont fait des suggestions de modifications sur les fiches qui ont toujours été prises en compte et intégrées. Pour le moment, on n’a pas rencontré le besoin d’un outil plus contributif. Les fiches sont sous Licence Creative-Commons Attribution – Partage à l’identique, ainsi quiconque peut s’en servir et les adapter. Pour l’animation d’un Gitlab, si les contributions et demandes d’un tel outil se multiplient, c’est clairement dans nos cordes et on l’envisagera, mais d’ici là si quelqu’un souhaite s’en charger qu’il n’hésite pas à nous contacter.

As-tu le sentiment que ce guide peut toucher notre fameuse famille-type, les Dupuis-Morizeau ? Ou alors c’est encore un peu trop geek pour eux ?

À force d’utiliser les outils valorisés par Framasoft, les Dupuis-Morizeau sont à mon avis bien plus compétents que nécessaire pour adopter les mesures du guide ! Blague à part, on a vraiment essayé d’être aussi pédagogique que possible avec ce travail. En fait, j’ai écrit les premières fiches comme un juriste, mais heureusement les autres membres du CECIL m’ont bien aidé à rendre ça intelligible ! On a cherché le bon équilibre entre rester aussi simple et clair que possible sans tomber dans l’approximation abusive. On est sur des enjeux qui touchent aux libertés individuelles de tout un·e chacun·e, il est nécessaire que tout le monde puisse s’en saisir.

Il n’y a pas besoin d’être expert·e ni même praticien·ne chevronné·e pour améliorer ses pratiques. Il suffit d’une volonté et d’avancer étape par étape. Je pense que les libristes le savent bien, passer à une distribution Gnu-Linux reste un grand saut pour beaucoup d’utilisateurs, par contre adopter un navigateur libre et quelques modules anti-traçage, arrêter d’utiliser Google pour toutes ses recherches, tester le navigateur TOR, chiffrer ses données sensibles… restent des pratiques assez simples.

Malheureusement, certains des outils que l’on préconise demandent un peu plus d’engagement personnel, qu’il s’agisse de passer à une messagerie sécurisée, à utiliser le chiffrement pour ses courriels (qui implique surtout que son entourage le fasse également), etc.
On espère par contre que les personnes qui ne réaliseront pas directement ces étapes après avoir lu le guide, en comprendront au moins les enjeux et l’importance. Si ce n’est pas pour aujourd’hui, peut-être demain ! J’ai très récemment rencontré une ancienne militante de beaucoup de combats de 82 ans à qui j’ai offert le guide, elle m’a promis de me faire un retour. Je vous le transmettrai avec plaisir !

Comme nous, tu fais des interventions auprès du grand public. As-tu ressenti une évolution des mentalités ? En gros, est-ce que nous changeons le monde, d’après toi ?

Oui les mentalités évoluent, mais comment ? Dans mes interventions militantes, il est assez clair que j’ai de moins en moins souvent à expliquer ce qu’est le logiciel libre. Reste que tout n’est pas rose pour autant. Malgré un travail de fond et systématique contre l’idiotie du « rien à cacher », l’argument revient encore trop souvent au détour d’un discours. Si ce n’est pas lui, le prétexte de la lutte (légitime) contre le terrorisme pour justifier l’adoption de mesures toujours plus restrictives des libertés est assommant et dur à combattre face à des publics peu engagés.

J’estime personnellement qu’il ne faut ni être naïf, ni résigné. Oui, nous participons à essayer de changer le monde, j’espère, pour le meilleur, malheureusement nos adversaires ne chôment pas pour autant et ont des moyens d’actions qui nous dépassent souvent. Pourtant dans les interstices quelques coins entrent toujours qui avec le temps et de la persévérance finiront par payer. Il y a des combats où tout reste à jouer, le traçage publicitaire en ligne par exemple ou la défense du droit au chiffrement où on est loin d’être démunis. Si on veut continuer à faire évoluer les mentalités, il faut donner à tout le monde la possibilité de comprendre ces enjeux. Pas un petit travail, mais au moins quand on respecte nos principes, la route est longue, mais la voie est libre !

Le mot de la fin est pour toi !

Pour ne pas oublier : un grand merci à Péhä pour sa superbe illustration (elle aussi sous licence libre évidemment) qui reflète à merveille les dangers de la jungle des Internets !

Sinon, je n’aime pas trop les fins, alors je vais tricher un peu en faisant une ouverture vers un pad pour lancer une tempête de cerveaux pour recueillir des idées (ou des trolls d’ailleurs !) pour lutter contre la surveillance illégitime et abusive en ligne. Que pourrions nous faire à l’échelon individuel comme collectif ?

Et si quelqu’un·e a un excellent projet et cherche une structure pour le mettre en œuvre, [il ne faut pas hésiter à nous rejoindre !

Pour conclure, j’en profite, avec un peu de retard (mais j’avais une bonne excuse !), pour souhaiter un joyeux anniversaire au Framablog et son équipe dont je suis un fidèle lecteur et traducteur occasionnel !

Acheter le guide

Le CECIL a mis en place une plateforme de paiement via la billetterie d’Helloasso.

Choisissez le nombre de guides souhaités (1, 2, 5 ou 10) et indiquez « 1 » en fin de ligne, puis suivez les étapes. Le tarif postal est identique quel que soit le pays.

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.

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

Lorsque l’on est en réunion, que l’on travaille en groupe, il faut prendre des notes. Pour cela, un Framapad, c’est plutôt pratique. Mais dès que vous voulez organiser ces notes, on en revient au tableau blanc avec les sempiternels papiers jaunes à bouts collants (dont on ne doit pas prononcer le nom)…

Du coup, nous on s’est dit « Ce serait-y pas formidable qu’un logiciel libre permette de simuler le tableau blanc et les papiers, de manière collaborative, comme les pads ? »

Et c’est là que nous avons découvert Scrumblr, de Ali Asaria ; qui a eu la belle idée de créer un logiciel compréhensible instinctivement, en deux clics. La suite, vous la devinez…

Framemo expliqué aux kanbanistes agiles

Oui, le tableau blanc, les colonnes et les papiers repositionnables, cela s’appelle du Kanban. Le passage qui suit est donc à réserver aux personnes qui connaissent déjà la méthode (ou veulent un bref aperçu de ce service). Si vous voulez une illustration explicative, pas de soucis, rendez-vous au titre suivant 😉 !

Framemo vous propose donc :

• De créer des tableaux kanban en ligne (sans ouverture de compte) ;
• De les partager via l’URL (adresse web) ;
• De travailler collaborativement en temps réel ;
• Le tout en mode cliquer-glisser-déposer ;
• L’édition, l’ajout et la suppression de colonnes ;
• L’édition, l’ajout et la suppression de notes (4 couleurs dispos) ;
• L’ajout ou le retrait de gommettes sur les notes ;
• L’ajout et l’édition du pseudonyme des participant-e-s ;

Ce service est basé sur le logiciel Scrumblr (participez-y ici), sous licence GNU GPL, et notre tuto pour l’installer sur vos serveurs est sur le Framacloud.

L’initiative Cot-Cot-Commons ouvre un Framemo

Prenons l’exemple (purement fictionnel) de Cot-Cot-Commons, une organisation qui voudrait créer un prototype de poulailler Libre (en plus d’être open source) et auto-géré, dans le jardin partagé de l’immeuble de Sandrine. Cette dernière s’y investit (elle aime réduire ses déchets végétaux) mais voit très vite que les idées fusent en réunion sans être forcément notées pour les personnes n’ayant pas pu venir. Qu’à cela ne tienne, lors de la réunion suivante, elle ouvre un Framemo !

Elle se rend donc sur Framemo.org et décide de créer un tableau sobrement intitulé « CotCotCommons« . Pas besoin de créer un compte, il suffit juste de taper le nom de son tableau et de cliquer sur « Allons-y » !

Bon, pour l’instant, il faut avouer que ce n’est pas super entraînant : un tableau tout vide, et quelques boutons « plus » et « moins » ici ou là, de petits points colorés…

En passant sa souris sur la droite du tableau, Sandrine fait apparaître un petit « plus » qui lui permet d’ajouter des colonnes. Lorsqu’elle clique sur leur titres, elle s’aperçoit qu’elle peut en modifier le nom. Sandrine prépare un tableau kanban assez classique (de toutes façons elle voit bien qu’on peut toujours modifier les noms de colonnes par la suite).

Notons au passage que Sandrine a vu qu’il suffisait de cliquer sur « Anonyme (vous) » pour entrer son prénom (ou son pseudo). Étant une habituée des pads, elle sait combien c’est pratique et met vite le sien.

Puis elle commence à noter les idées du compte rendu de la séance précédente. Pour créer une note, elle clique sur le « plus » à gauche sous le tableau. Un petit papier apparaît qui ne demande qu’à être édité, puis déplacé d’un geste de la souris…

Sandrine n’y tient plus, elle finit juste quelques notes avant que de partager l’adresse web du tableau avec le reste de Cot-Cot-Commons. Elle est facile à retenir c’est le nom du site puis le nom de son tableau : framemo.org/CotCotCommons

Très vite, Abdel, le secrétaire de séance, décide de projeter le tableau sur le mur de la salle de réunion. Dans le groupe, plusieurs s’emparent de leurs ordinateurs (dont Naya, restée chez elle à cause d’une jambe cassée, qui participe donc en visio conf) pour réorganiser les notes de Sandrine et y ajouter leurs idées !

C’est d’ailleurs Naya qui découvre qu’on peut glisser et déposer sur chacune des notes les gommettes qui se trouvent en bas à droite. Le groupe décide donc d’un code couleur pour attribuer les tâches à chacun-e. Bien vite, il y a tant de notes qu’il leur faut agrandir le tableau (en le tirant vers le bas d’un simple geste de la souris !)

À vous de tester (et partager) Framemo !

Et voilà : Ali Asaria (et toute l’équipe de Scrumblr) nous propose là un petit service efficace, pratique, facile d’accès… L’idéal pour collaborer aisément sans avoir à apprendre et à s’habituer à un logiciel plus complexe !

Car si le collectif Cot-Cot-Commons est une pure invention, nous sommes certains que Framemo peut être utile à vos associations, syndicats, familles, entreprises, institutions : bref, dans tous les cercles où vous vous organisez en commun.

Et si vous trouvez Framemo trop léger pour vos besoins, nous vous rappelons qu’il existe un outil plus orienté gestion de projets – et donc plus complexe – nommé Framaboard.org utilisant lui aussi la méthode kanban.

Nous sommes ravis de pouvoir vous proposer ce nouveau service, et attendons de voir avec impatience si vous allez vous en emparer, l’utiliser, le partager… et surtout le quitter parce que vous l’aurez finalement adopté sur vos serveurs 😉 !

Pour aller plus loin :

• Tester Framemo
• Découvrir Scrumblr
• Installer Scrumblr sur vos serveurs