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.

Clicnat, une application pour trouver les plages naturistes cet été ? Pas vraiment, c’est plutôt le Pokemon Go de Picardie…

Mais un Pokemon Go en réalité réelle (même pas besoin de l’augmenter :p) et avec des bestioles de toutes sortes : grâce à l’association Picardie Nature, vos balades peuvent alimenter les données naturalistes locales, et en plus, c’est libre !

Notre Fred avait rencontré l’été dernier (lors des RMLL de Beauvais) la joyeuse troupe de cette association, mais (tout au peaufinage de son polar) il n’a pas pu réaliser l’interview.

Qu’à cela ne tienne, l’intrépide Tripou, un des Framacolibris furetant sur le forum des bénévoles de Framasoft, a pris le relais, et est allé interroger Picardie Nature pour qu’ils nous en apprennent plus sur Clicnat.

Pourquoi avoir choisi le libre pour Clicnat ?

C’est déjà un réflexe naturel, Picardie Nature utilise du logiciel libre et partage ce qu’elle produit, la plus grande partie des postes de travail est sous Ubuntu. Mais aussi parce qu’on a souhaité qu’il soit accessible à d’autres et au-delà de la Picardie. De cette façon, l’effort qu’on a fourni pour le créer ne devrait pas être à nouveau mobilisé et l’énergie qu’on y apportera doit servir à en faire quelque chose de mieux.

Ceux que ça intéresse peuvent aussi regarder comment c’est fait, comment ça marche et il y a aussi forcément l’argument économique qui va devenir prépondérant dans le contexte actuel où la fonte de nos subventions est indexée à celle des glaciers.

C’est pour nous aussi un moyen d’indépendance, le maintien en ligne uniquement pour la saisie des données peut ne coûter qu’une machine et un peu de temps bénévole. C’est le travail de développement, d’animation, de mise en circulation des données qui sera impacté, l’existant peut être préservé et on pourra toujours continuer à noter nos observations.

Est-ce parce que Sterne et BDN (utilisés à l’ONF) ne vous convenaient pas, que vous avez choisi de développer une application libre?

Avant de se lancer on a testé plusieurs outils, on a pu accéder au code et en installer certains. Ces applications ont certainement eu une évolution depuis mais a ce moment-là pour nous elles étaient, selon nous, trop orientées vers un public scientifique et leur module cartographique ne nous satisfaisait pas. On s’approchait de ce qu’on voulait faire mais sans l’atteindre.

Clicnat a été créé avec des logiciels libres, lesquels ? (OpenLayers pour la cartographie, mais encore) ?

Clicnat est principalement écrit en PHP, pour la base de données c’est PostgreSQL avec PostGis et on utilise également MongoDB. Sur l’interface on a effectivement OpenLayers pour la cartographie et aussi l’incontournable jQuery. En ce moment on commence à introduire React dans les interfaces, on s’attaque aussi au développement pour les mobiles avec Cordova en utilisant toujours React et OpenLayers.

Il n’y a pas encore de standard d’échange de données dans le monde naturaliste. Comment fait-on, alors ?

On parle souvent de la même chose, au minimum, une date, un lieu, une espèce ou taxon. Pour les deux premiers on s’en sort bien, c’est une fois qu’on discute de l’espèce ou du taxon que ça commence à se compliquer.

Les noms changent régulièrement au fil du temps, certains peuvent être regroupés ou séparés en plusieurs nouveaux taxons, c’est là qu’il faut s’entendre sur un référentiel, Clicnat a son propre référentiel et on utilise le référentiel taxonomique TAXREF, qui est géré par le Muséum national d’histoire naturelle, pour les échanges, et qui devient maintenant un standard.

En France le Muséum national d’histoire naturelle propose aussi un standard d’échange, et travaille à la mise en place du SINP pour faire circuler les données. Au niveau international il y a le Système mondial d’information sur la biodiversité (GBIF) qui existe aussi, on peut accéder aux données via des API (interface de programmation applicative), c’est très ouvert.

Qui rédige les fiches espèces auxquelles on peut accéder ?

Principalement des naturalistes picards, les textes pour les oiseaux viennent du livre Les oiseaux de Picardie. Certains ont été écrits par des stagiaires ou CDD, c’est un exercice que l’on peut faire pour acquérir la connaissance locale pour une espèce qui va faire l’objet d’une étude.

Si on ne connaît pas l’espèce que l’on croise, c’est gênant pour alimenter Clicnat ?

Ça n’est pas gênant, il y a des processus de validation et de contrôle, votre observation ne fera pas obstacle à la construction d’une autoroute si elle est farfelue. L’erreur est permise et c’est aussi un des premiers contacts que vous aurez avec un humain qui va vous questionner sur votre observation peut-être inhabituelle.

Et selon le contexte d’utilisation on va adapter le niveau d’exigence pour une donnée d’observation, dans le cadre d’une action en justice ou pour évaluer l’impact d’un projet on va regarder à la loupe ce qui est rapporté. Si on ne connaît pas l’auteur, que la présence de cette bestiole implique de gros enjeux, on va vous demander d’étayer éventuellement avec une photo et de répondre à quelques questions pour évacuer une confusion avec une autre espèce par exemple et on saura dire si ça tient la route ou pas.

La donnée devient fiable à quel moment ? C’est à dire on observe un animal à un endroit précis, on va l’inscrire sur Clicnat et on sait que tel jour à tel moment un éléphant était devant la poste ?

Une fois que deux utilisateurs validateurs ont donné un avis favorable ou que le coordinateur du réseau faunistique concerné l’a validée manuellement dans un lot.

L’accumulation des données est traitée différemment ? Un troupeau d’éléphants passe chaque année à cette période devant la poste ?

Non, Clicnat est principalement un entrepôt et une ressource pour ceux qui vont écrire un article. Le travail d’étude est principalement fait en dehors de Clicnat mais il commence par une extraction de données de celui-ci. Et plus il y a de données, mieux c’est. Ça va permettre d’affiner les dates d’arrivée et de départ de certaines espèces, de détecter des régressions ou progressions d’espèces, de mesurer l’impact du réchauffement climatique.

C’est aussi un point d’échange, en Picardie et en Normandie les plateformes regroupent plusieurs structures qui mettent leur données en commun sur leur plateforme.

Existe-t-il un équivalent pour la flore ?

Oui, il y a Digitale 2 qui est porté par le CBNBL dans le Nord Ouest mais qui n’est pas libre.

Ça peut être pas mal pour alimenter la page Wikipédia sur la faune de Picardie dont les références les plus récentes datent de 1994. C’est prévu ou vous allez laisser faire les particuliers ?

L’article sur Picardie Nature a été supprimé de Wikipédia parce qu’on manque de notoriété d’après les critères wikipédiesques. Ça nous a laissé un goût amer, pour l’instant ça n’est pas prévu de notre côté.

Sur la carte on peut voir que Rouen ne participe pas du tout au référencement… à tous les coups son excuse sera probablement que ce n’est pas le même département…tst.

C’est normal on couvre la Picardie. Mais c’est une autre instance de Clicnat quand même. Le GONm utilise aussi Clicnat, on est encore dans une phase de déploiement pour la partie restitution. On a dû faire pas mal de modifications pour que le projet puisse tourner sur une autre région. Il y avait pas mal de choses dans le code qui nous étaient spécifiques et on a dû procéder à pas mal de nettoyage. Ça nous a servi de leçon et maintenant on est plus générique sur la façon de développer.

C’est le hasard mais j’ai entendu parler d’un système similaire il y a quelques jours : Silène, qui référence également la faune et la flore dans le sud de la France, vous vous inspirez entre vous, vous discutez, ou c’est cloisonné ?

Il n’y a pas beaucoup d’échanges entre bases, c’est vrai que c’est plutôt cloisonné. On regarde évidemment ce que les autres font, j’aime ce que fait Sigogne par exemple. Sinon les attentes des utilisateurs suffisent pour nourrir la réflexion et faire germer les idées.

Y’a t-il ce genre de système dans chaque région ?

Oui, pour ceux portés par des associations de naturalistes, le plus répandu est Visionature, ensuite il y a des choses comme Clicnat (Picardie, Normandie) et SIRF (Nord Pas de Calais)

D’autres régions/départements vous ont-elles contacté pour mettre en place ce type de dispositif ?

Évidemment la Normandie, on a aussi Faune-et-route, un morceau de Clicnat dédié au collisions routières, qui est porté également à présent par le CPIE de la Mayenne. On commence à être sollicité par d’autres régions et de temps en temps quelqu’un demande à accéder au dépôt du code.

Clicnat permet également de produire des synthèses, c’est-à-dire ?

C’est ce qu’on appelle entre nous le site public, il permet à tout le monde de consulter et télécharger les données de répartition des espèces.

Alors, si je comprends bien, étant braconnier revendeur d’espèces en danger, je peux aller sur Clicnat pour m’informer des meilleurs endroits pour les choper ?

Non, parce qu’on va flouter géographiquement la localisation sur des mailles de 5km2 et parfois ne pas indiquer les communes. On ne dévoile pas les indices de reproduction ou le comportement des espèces qui pourraient dire dans quel milieu elles se trouvaient.

Quand on travaille avec des bureaux d’études ou avec les fonctionnaires qui instruisent des dossiers liés à l’environnement, on passe au kilomètre carré. Et ensuite au cas par cas, pour de la rédaction d’articles, pour la contribution à un projet particulier ou pour des actions en justice, on peut extraire les données brutes avec un maximum de précision.

Sur quel animal menacé voudriez-vous attirer l’attention ?

Aucun, ils sont tous intéressants et méritent tous notre attention. Une espèce commune aujourd’hui pourra devenir menacée demain, et si personne ne prend le temps de les noter régulièrement on le verra pas venir. Quand on soupçonnera qu’il se passe quelque chose, on ne pourra pas étayer d’hypothèse avec des observations.

Pour aller plus loin :

• Le site de l’association Picardie Nature
• Découvrez Clicnat
• Le code source de Clicnat (licence AGPL V3)

Dans le mode du logiciel libre, et contrairement à ce que le nom laisse suggérer, ce n’est pas le logiciel qui est libre, mais bien l’utilisateur du logiciel.

Le logiciel propriétaire, c’est-à-dire l’opposé du logiciel libre, est alors parfois appelé « logiciel privateur », car il prive l’utilisateur de certaines libertés fondamentales (étudier, exécuter, etc. le code source du programme).

Rebecca Wexler, étudiante dans l’école de droit de Yale (Yale Law School) nous montre ici qu’en plus ne nous priver de ces libertés qui peuvent parfois sembler bien futiles pour tout un chacun, ces logiciels peuvent compromettre le système judiciaire et nous priver ainsi de nos libertés fondamentales.

Condamnés par le code

par Rebecca Wexler

Source : Convicted by code (Slate)

Traduction :Vincent,  McGregor, roptat, oS,Diane, CLC, touriste, teromene, Piup, Obny et anonymes.

Le code « secret » est partout : dans les ascenseurs, les avions, les appareils médicaux.

En refusant de publier le code source de leurs logiciels, les entreprises rendent impossible son inspection par des tiers, et ce même si le code a un impact énorme sur la société et la politique. Verrouiller l’accès au code empêche de connaître les failles de sécurité qui peuvent nous rendre vulnérables au piratage et à la fuite de données. Cela peut menacer notre vie privée en accumulant de l’information sur nous à notre insu. Cela peut interférer avec le principe d’égalité devant la loi si le gouvernement s’en sert pour vérifier notre éligibilité à une allocation, ou nous inscrire sur une liste d’interdiction de vol. De plus, le code gardé secret permet le trucage des données et occulte les erreurs, comme dans l’affaire Volkswagen : l’entreprise a récemment avoué avoir utilisé un logiciel caché pour truquer les tests d’émission menés sur 11 millions de voitures, qui rejetaient l’équivalent de 40 fois la limite légale.

Mais aussi choquante que la fraude de Volkswagen puisse être, elle ne fait qu’en annoncer bien d’autres du même genre. Il est temps de s’occuper de l’un des problèmes de transparence technologique les plus urgents et les plus négligés : les programmes secrets dans le système judiciaire. Aujourd’hui, des logiciels fermés, propriétaires, peuvent vous envoyer en prison et même dans le couloir de la mort. Et dans la plupart des juridictions des États-Unis, vous n’avez pourtant pas le droit de les inspecter. Pour faire court, les procureurs ont le même problème que Volkswagen.

Prenons la Californie. Martell Chubbs est actuellement accusé de meurtre pour des faits remontant à 1977, dans lesquels la seule preuve contre lui est une analyse ADN effectuée par un logiciel propriétaire. Chubbs, qui dirigeait une petite entreprise de dépannage à domicile à l’époque de son arrestation, a demandé à inspecter le code source du logiciel afin de pouvoir contester la précision de ses résultats. Il cherchait à déterminer si le code implémente correctement les procédures scientifiques établies pour l’analyse ADN et s’il fonctionne comme son fabriquant le prétend. Mais ce dernier a affirmé que l’avocat de la défense pourrait voler ou dupliquer le code et causer des pertes financières à l’entreprise. Le tribunal a rejeté la requête de Chubbs, lui autorisant l’examen du rapport de l’expert de l’état, mais pas l’outil qu’il a utilisé. Des tribunaux de Pennsylvanie, Caroline du Nord, Floride et d’autres ont rendu des décisions similaires.

Nous devons faire confiance aux nouvelles technologies pour nous aider à trouver et condamner les criminels, mais aussi pour disculper les innocents. Les logiciels propriétaires interfèrent avec cette confiance dans de plus en plus d’outils d’investigation, des tests ADN aux logiciels de reconnaissance faciale et aux algorithmes qui indiquent à la police où chercher les futurs crimes. Inspecter les logiciels n’est cependant pas seulement bon pour les accusés : divulguer le code à des experts de la défense a permis à la Cour suprême du New Jersey de confirmer la fiabilité scientifique d’un éthylotest.

Non seulement il est injuste de court-circuiter la possibilité pour la défense de contre-expertiser les preuves médico-légales, mais cela ouvre la voie à de mauvaises pratiques scientifiques. Les experts décrivent la contre-expertise comme « le meilleur instrument légal jamais inventé pour la recherche de la vérité ». Mais des révélations récentes ont révélé une épidémie de mauvaises pratiques scientifiques qui sapent la justice criminelle. Des études ont contesté la validité scientifique des recherche de similitudes sur les marques de morsure, les cheveux et les fibres, des diagnostics du syndrome du bébé secoué, de techniques balistiques, des séances d’identifications olfactives par des chiens, des preuves issues de l’interprétation de taches de sang, et des correspondances d’empreintes digitales. Le Massachusetts se démène pour gérer les retombées des falsifications de résultats par un technicien d’un laboratoire criminel qui a contaminé les preuves de dizaines de milliers d’affaires criminelles. Et le Projet Innocence rapporte que de mauvaises analyses légales ont contribué à l’incrimination injustifiée de 47% des prévenus. L’Académie Nationale des Sciences (National Academy of Sciences) accuse entre autres le manque de processus d’évaluation par les pairs dans les disciplines liées à l’analyse légale d’être responsable de cette crise.

Les logiciels ne sont pas non plus infaillibles. On a découvert des erreurs de programmation qui changent les ratios de probabilité des tests ADN d’un facteur 10, amenant des procureurs australiens à remplacer 24 avis d’experts dans des affaires criminelles. Quand les experts de la défense ont identifié une erreur dans le logiciel de l’éthylotest, la Cour suprême du Minnesota a invalidé le test en tant que preuve pour tous les futurs jugements. Trois des plus hautes cours de l’état (américain, NdT) ont encouragé à accepter davantage de preuves de failles dans des programmes, de manière à ce que les accusés puissent mettre en cause la crédibilité de futurs tests.

La contre-expertise peut aider à protéger contre les erreurs – et même les fraudes – dans la science et la technique de l’analyse légale. Mais pour que cet appareil judiciaire puisse fonctionner, l’accusé doit connaître les fondements des accusations de l’état. En effet, lorsque le juge fédéral de Manhattan, Jed S. Rakoff, a démissionné en signe de protestation contre la commission sur les sciences légales du président Obama, il a prévenu que si l’accusé n’a pas accès à toutes les informations pour effectuer une contre-expertise, alors le témoignage d’un expert judiciaire n’est « rien d’autre qu’un procès par embuscade » (c.-à-d. sans accès préalable aux éléments  de preuve, NdT).

La mise en garde de Rakoff est particulièrement pertinente pour les logiciels des outils d’analyse légale. Puisque éliminer les erreurs d’un code est très difficile, les experts ont adopté l’ouverture à l’analyse publique comme le moyen le plus sûr de garder un logiciel sécurisé. De manière identique, demander au gouvernement d’utiliser exclusivement des outils d’analyse légale ouverts permettrait leur contre-expertise participative. Les fabricants d’outils d’analyse légale, qui vendent exclusivement aux laboratoires d’expertise criminelle du gouvernement, peuvent manquer de motivations pour conduire les tests de qualité minutieux requis.

Pour en être certains, les régulateurs du gouvernement conduisent actuellement des tests de validation pour au moins quelques outils d’analyse légale numériques. Mais même les régulateurs peuvent être incapables d’auditer le code des appareils qu’ils testent, se contentant à la place d’évaluer comment ces technologies se comportent dans un environnement contrôlé en laboratoire. De tels tests « en boite noire » n’ont pas été suffisants à l’Agence de Protection de l’Environnement (Environmental Protection Agency) pour repérer la fraude de Volkswagen et ce ne sera pas non plus assez pour garantir la qualité des technologies numériques d’analyse légale.

La Cour suprême a depuis longtemps reconnu que rendre les procès transparents aide à s’assurer de la confiance du public dans leur équité et leur légitimité. Le secret de ce qu’il y a sous le capot des appareils d’informatique légale jette un doute sur ce processus. Les accusés qui risquent l’incarcération ou la peine de mort devraient avoir le droit d’inspecter les codes secrets des appareils utilisés pour les condamner.

Le logiciel libre a un important rôle à jouer dans la manipulation de données géographiques, qui doivent impérativement rester un bien commun. À l’occasion d’un rassemblement des acteurs de ce milieu, nous avons demandé à en savoir plus.

Salut Étienne. Tu es le président de l’association OSGeo-fr qui selon son site « est la représentation Francophone de la fondation Open Source Geospatial dont la mission est d’aider et de promouvoir le développement collaboratif des données et des technologies géospatiales ouvertes. »

J’ai rien compris. C’est quoi, le géospatial ?

Alors le Géospatial, ça ressemble un peu à un pléonasme, Géo pour géographique et spatiale pour l’espace. Bon en ce qui nous concerne, le géospatial renvoie au Système d’information géographique (SIG ou encore GIS en anglais). Les SIG sont à considérer comme une architecture, un système, informatique pour stocker et traiter des données géographiques.

L’OSGeo-fr est une association française qui est née il y a 10 ans pour donner de la visibilité aux logiciels libres en géographie (géomatique). Le fr c’est parce que nous sommes le « chapitre » (comme les loges maçonniques :-)) français d’une fondation internationale : http://www.osgeo.org/.

Parmi nos actions, nous organisons le FOSS4G-fr tous les deux ans à Paris en partenariat avec l’ENSG, des rencontres utilisateurs Qgis tout les ans à Montpellier avec les étudiants du Master AgroTIC, des semaines de traduction des interfaces et de la documentation pour les logiciels incubés par l’OSGeo. Cette année nous avons également soutenu un CodeSprint de l’OSGeo à Paris en début d’année.

Notre objectif vise à rassembler et dynamiser la communauté des développeurs et des utilisateurs francophone. La première édition du FOSS4G-fr a eu lieu en 2014 sur 3 jours à l’ENSG de Marne-la-Vallée, et a rassemblé 250 personnes.

Nous relancerons la machine pour 2016.

C’est toujours pas super clair.

Nous, à l’OSGeo, ce qui nous occupe, nous intéresse et nous passionne, ce sont tous les outils qui permettent de construire des cartes. Les contributeurs d’OpenStreetMap le savent, avant d’aboutir à une carte comme la Top25 de l’IGN ou à la carte OSM, un travail de sélection et de mise en forme de l’information doit être fait. On peut identifier plusieurs phases dans le processus et pour chaque phase, il existe une constellation de logiciels libres pour aider l’Homme dans cette tâche.

La création de données : comme dans OSM, on part bien souvent de photos aériennes, et on peut numériser à la main les différentes formes qu’on observe. Eh bien il existe d’autres méthodes qui consistent à faire construire ces formes par l’ordinateur. On pourra par exemple parler de GRASS-GIS, orfeo-toolbox ou encore R avec certains packages. L’évolution des capteurs d’acquisition de données (photos multi-band, infrarouge, LIDAR, etc.) ouvre régulièrement de nouvelles applications et de nouvelles possibilités dans le traitement de la donnée spatiale.

Donc pour revenir à la question, les technologies géospatiales manipulent des données dont l’objet est l’espace, sa représentation et sa modélisation.

Pourquoi le fait de travailler avec des logiciels libres est-il si important ? Que se passerait-il si la discipline était noyautée par les GAFAM ? Par l’Oncle Sam ?

Quand on parle de logiciel libre personnellement je pense immédiatement à des questions de justice sociale et justice spatiale (ben oui :-p). La cartographie est initialement un outil mobilisé pour la conquête. Qu’on pense au militaire ou au navigateur, leurs objectifs étaient de prendre possession de l’espace. Quand j’ai commencé à travailler avec des outils géomatiques, le libre existait bien sûr, mais il n’avait pas le droit de cité dans ma formation. Et je me suis retrouvé en stage dans une structure qui n’avait pas les moyens de se doter de logiciels « métier ».

Le logiciel libre a été un moyen de s’émanciper de cette contrainte et de permettre à la structure en question de pouvoir continuer à utiliser mon travail. Aujourd’hui les choses ont beaucoup changé, en grande partie grâce à Qgis qui a complètement redistribué les cartes (haha). De plus en plus de formations proposent des cours sur Qgis en plus des outils plus « traditionnels », et le dynamisme de la communauté des utilisateurs et des développeurs y est pour beaucoup !

Le web n’est pas à la traîne, openLayer est une librairie JavaScript incontournable, postgreSQL et PostGIS pour le stockage en base de données se sont largement imposés, etc . Donc pour moi les logiciels libres de l’OSGeo répondent bien aux questions de justice sociale en permettant à tous d’avoir accès à des logiciels et des algorithmes de qualité, ce qui nous conduit à la justice spatiale… il n’y a plus de contraintes à ce que la terre soit cartographiée par les gens qui la vivent !

Pour ce qui en est de l’oncle Sam… eh bien GRASS-GIS par exemple à été développé au départ par l’armée américaine et donné à la communauté.  Pour les GAFAM, ils restent ambigus non ? Google pour ne citer que lui a largement contribué à diffuser la cartographie sur Internet. Mais bien sûr la licence d’utilisation n’est pas acceptable ! On ne pourra pas non plus identifier combien de développements ont été permis grâce au Google Summer Of Code… Bon je parle beaucoup de Google… Peut-être que les autres sont moins ambigus ! :-p

Les données sont donc libres aussi (opendata) ?

Bien sûr, on parle aussi d’OpenData en géomatique ! La première source à laquelle on pense est bien sûr Openstreetmap et sa communauté qui font un travail formidable, aussi bien en ce qui concerne la numérisation de données que l’alignement avec d’autres référentiels. En France, par exemple, je ne sais pas si vous avez suivi, mais le projet Bano est assez exemplaire. L’idée repose sur une convention entre  l’IGN, le Groupe La Poste, l’État et OpenStreetMap France pour proposer la BAN (Base Adresse Nationale), qui sera la base de données adresse de référence en France.

Mais pour les gens qui veulent traiter d’autres données on trouve beaucoup d’autres sources sur internet : STRM, ASTER…

Vous avez l’air très dynamiques : deux réunions en France en mai, une autre à Bonn en août. Vous avez beaucoup de choses à vous dire ou c’est pour manger des petits fours entre copains ?

Du dynamisme ! Oui oui on fait ce qu’on peut. 🙂

La communauté Osgeo-fr est nationale il faut donc arriver à créer des événements conviviaux pour que l’investissement en temps soit agréable ! Pour les francophones il y a donc cette année trois rendez-vous. Le premier est déjà passé et s’est déroulé à Montpellier en partenariat avec le Master AgroTIC de SupAgro. Ce rassemblement était dédié à Qgis et plutôt orienté utilisateurs et retour d’expérience.

Le second aussi est passé, il s’adressait plutôt aux développeurs : il s’agissait d’un code Sprint organisé à Paris en début d’année. L’objectif est de rassembler pendant un certain temps des développeurs pour avancer de concert au développement de nouvelles fonctionnalités et à la correction de bugs.

Enfin l’événement à venir, j’en ai déjà touché deux mots en introduction, est une rencontre plus large orientée tout à la fois développeurs et utilisateurs avec deux sessions parallèles. Le programme est sorti et il est incroyablement intéressant avec 10 workshops et 41 conférences en 3 jours. De quoi mettre le pied à l’étrier si vous êtes intéressés par les technologies géospatiales !

Nous organisons également des événements en ligne comme une semaine de traduction. À ce moment là, les personnes motivées se retrouvent dans des salons IRC pour avancer là aussi de manière concertée sur la traduction des interfaces et de la documentation pour permettre au plus grand nombre d’utiliser les logiciels.

Quel est l’avenir de la discipline ?

La prospective est toujours un exercice difficile parce qu’on passe toujours à côté de quelque chose ! Aujourd’hui si je réfléchis un peu aux évolutions depuis notre dernière édition du FOSS4G-fr : les technologies webSIG semblent se stabiliser après la sortie d’OpenLayers 3, on gère bien les données grâce des SGBD toujours plus performants, les web-services WMS, WFS, WPS, s’ils sont toujours en ébullition, sont déjà utilisables par la communauté.

La gestion de données 3D en base de données avait fait l’objet de plusieurs ateliers et présentations l’année dernière. Il semble que cette année le logiciel libre en géomatique et le géospatial s’investissent largement dans le traitement de données issues de drones, ce qui bien sûr remettra sous les spotlights le stockage.

Dans un autre domaine, la gestion des métadonnées géographiques reste également une question brûlante surtout avec l’émergence des organismes de diffusion de données de géographie produites par les territoires.

Pour conclure, le spatial prend de plus en plus d’espace dans les préoccupations, ce qui conduira de plus en plus de gens à migrer vers des outils open source ou libres pour reprendre la main sur ces données. Pour preuve un certain nombre de présentations au FOSS4G-fr de cette année sont des retours d’expérience de migration, de financement, par des entreprises, des associations ou des services de l’État vers le logiciel libre en géographie.

Est-ce que le grand public peut vous aider ? Ça a l’air d’un nid d’universitaires super-pointus, votre bidule…

Des universitaires ? Pas tant que ça 🙂 ! Pour le grand public, il me semble que si la question ne se pose pas encore pour tout le monde, nous allons vers une généralisation de l’utilisation des données géographiques. Quand le besoin se fait sentir, les solutions émergent. Aujourd’hui s’il est vrai que certaines solutions nécessitent quelques compétences, d’autres comme Qgis, gvSIG ou OpenJump pour n’en citer que trois sont à la portée du plus grand nombre.

Par ailleurs si vous voulez essayer toutes les saveurs des outils Osgeo, vous pouvez télécharger le live DVD traduit par la communauté.

C’est sans doute un bon moyen d’explorer les solutions simples comme les architectures plus compliquées sans complexe ni découragement. Si cela pique votre curiosité n’hésitez pas à venir rencontrer d’autres utilisateurs et développeurs au FOSS4G-fr, aux rencontres Qgis, ou au GeoCamp organisés dans différentes villes de France. Des moments de partage et de convivialité après lesquels tous les participants ressortent plus riches.

Pour en voir plus, une vidéo sur l’impressionnant plugin Cadastre

http://www.osgeo.asso.fr/

Le 18 février dernier le tribunal administratif de Paris, après avis de la Commission d’Accès aux Documents Administratifs (CADA), a rendu une décision autorisant l’accès d’un citoyen au code source d’un logiciel administratif. Génial, non ?

Non, pas vraiment, puisque dit comme ça on n’y comprend rien ! Et pourtant ce jugement pourrait avoir un grand impact sur l’avenir du libre en France et plus généralement sur la vie de tous les citoyens. On va donc essayer d’y voir plus clair.

Res Publicum, la chose publique

Pour comprendre ce qui s’est passé le 18 février dernier, il faut que je vous parle un peu des documents administratifs en France. Un document administratif c’est tout ce que peut produire une administration publique : statistiques, rapports, analyses et même logiciels.

Si certains de ces documents sont publics dès les départ (les communiqués de presse par exemple), d’autres n’ont pas forcément vocation à être rendus publics. Et pourtant la République c’est notre bien à tous (Res Publicum, ça veut dire la chose publique), tout citoyen peut donc demander à une administration de lui communiquer un document qu’elle a produit et qui n’est pas classé secret-défense, bien entendu.

Depuis 1978 une administration a même été créée pour s’occuper de cela spécifiquement, la CADA. En réalité, cette administration ne peut rendre que des avis et joue plus un rôle de médiateur entre une administration et un citoyen, mais elle reste très utile.

Un étudiant tenace…

Revenons à notre affaire. Un étudiant en économie un peu curieux a demandé en 2014 au Ministère de l’économie et des finances (Bercy) de lui transmettre le code source du logiciel de calcul de l’impôt. Un code source, c’est en quelque sorte la recette de cuisine du logiciel, ce qui permet de comprendre comment il fonctionne

Bercy a refusé et notre étudiant a alors saisi la CADA qui a dit que selon elle le code source devait être transmis. Deuxième refus de Bercy.

Notre étudiant a alors saisi le tribunal administratif de Paris pour forcer Bercy à lui remettre le document demandé. À ce moment le ministère a compris que tout cela sentait mauvais pour lui et a préféré s’exécuter avant le jugement. Malgré tout le tribunal a rendu sa décision le 10 mars dernier et a dit que l’étudiant avait raison. Victoire !

Le code source, c’est la recette de cuisine du logiciel

Maintenant vous devez vous dire, tant mieux pour cet étudiant mais concrètement ça sert à quoi ? Et c’est vrai que dit comme ça ce n’est pas très utile. Ce n’est pas parce que le code du logiciel est connu qu’il est libre et donc vous n’aurez pas le droit de modifier ou partager librement ce code. Autrement dit, on peut lire, cuisiner, mais pas gribouiller sur la recette originale, même pour y ajouter de meilleures ingrédients. En revanche vous pourrez toujours le consulter et pourquoi pas trouver des erreurs, des améliorations possibles et les proposer à Bercy qui pourrait les intégrer à son logiciel.

Imaginez un peu que vous arriviez à faire baisser le montant de vos impôts en remarquant une erreur dans le code. Pas si inutile, finalement ! En partant de cet exemple on peut imaginer beaucoup de cas où les citoyens pourraient contribuer à améliorer l’État. Prenons un exemple… Mme Dupuis-Morizeau a du temps libre et décide donc de consulter les statistiques d’accidents de la route de sa ville, qu’elle demande à la mairie. Elle remarque alors un carrefour particulièrement meurtrier, elle se rend sur place et constate que le panneau stop est caché par un buisson. Elle avertit sa mairie qui fait couper le buisson. Et voilà comment l’accès à des statistiques administratives peut sauver de vies !

La philosophie du Libre appliquée à l’État

Le problème, vous l’avez vu, c’est que demander un document administratif peut s’avérer très compliqué et que Mme Dupuis-Morizeau n’a pas forcément tout ce temps à perdre. On se dit alors que ce serait génial que tous ces documents soient librement téléchargeables sur un site internet.

Eh bien c’est exactement ce que s’est dit la ville de New-York qui publie tous les documents qu’elle produit (ou presque) sur le site https://nycopendata.socrata.com/. Depuis que la ville a adopté cette politique, des dizaines de citoyens se sont mis au travail pour créer des projets incroyables : dresser la carte des plages anormalement polluées, coder un GPS pour les ambulances en fonction des vitesses moyennes par rue pour optimiser les trajets, etc.

Voilà les avantages concrets de la philosophie du libre lorsqu’elle est appliquée à l’État. Nous pouvons tous contribuer à un fonctionnement meilleur de l’administration, ou du moins à signaler ses défauts. Rendre les documents administratifs libres, c’est faire du citoyen le réel propriétaire de l’administration qui le sert, comme nous sommes collectivement les propriétaires des logiciels libres. Beau projet non ?

Trois infos pour finir et approfondir le sujet si ça vous dit :

• Le code source du logiciel de calcul de l’impôt sera rendu public le 1er avril et un hackaton est organisé sur le git de Framasoft pour fêter ça. Ça se passe par ici pour les infos.
• La décision du tribunal administratif de Paris est à lire ici (attention c’est technique).
• Pour comprendre tout ce qu’a fait la ville de New-York en rendant libres ses documents vous pouvez regarder l’excellente conférence TED sur le sujet.

L’équipe du Framablog tient à remercier chaleureusement Róka, bénévole du forum des Framacolibris, pour la proposition et la rédaction de cet article !

Ah… il n’est pas si loin, le temps des réveillons et des repas de famille. Les retrouvailles, les dîners où l’on découvre sa belle-famille, les conversations qui défont et refont le monde… Seulement voilà, quand on travaille dans l’open source il est une question que l’on redoute particulièrement : « Mais dis-moi, ça consiste en quoi, ton travail, en fait ? »

Quelques fourchettes se posent, quelques nuques se tendent, l’oreille aux aguets. Il faut dire que, chez les Dupuis-Morizeau (notre sympathique famille-témoin qui a pris le relais des « Michus » depuis leur Normandie natale) l’open source relève de la charade…

On sait qu’il s’agit d’informatique. D’une informatique plutôt… « bien », comme ces légumes des AMAP qui ont meilleure presse que ceux des supermarchés. Mais… en quoi est-ce un métier ? Comment peut-on y gagner sa vie ? Est-ce réaliste dans notre monde où l’économie fait loi…?

Voici donc un petit guide pour expliquer le logiciel libre à votre belle-famille, lors de vos prochaines vacances.

Pouhiou.

Comment impressionner sa belle famille

L’open source pour les non-techniciens.

par Brian Proffitt.

Article original paru sur le blog de RedHat

Traduction Framalang : Simon, sinma, lamessen, McKael, goofy, niilos, nilux, Bussy, niilos, r0u, Tim, audionuma, r0u, Diab, et les anonymes…

En repensant à ces dernières vacances, je dois dire qu’au final, c’était plutôt détendu (ce n’est pas toujours acquis lorsque les proches font partie de l’équation.)

Cette année, j’ai passé Noël avec ma belle-famille et c’était la première fois qu’on se voyait vraiment depuis que j’ai commencé à travailler sur le projet oVirt. Tout ce que ma belle-famille savait était que j’avais obtenu un nouveau travail et que je voyageais beaucoup. Ce qui, naturellement, a suscité l’inévitable question : qu’est ce donc que je fais exactement ?

Difficile de répondre à cela aux gens en dehors du monde des TIC. Si je dis à un groupe de confrères, « je suis un animateur de communauté open source », je peux être raisonnablement sûr qu’ils auront au moins compris partiellement. Ils seront certainement encore à côté (de la plaque) dans leurs suppositions (« tu es un de ces hippies ? »), mais au moins on sera sur le terrain de la compréhension.

En-dehors des TIC, non seulement nous ne jouons pas dans la même cour de récré, mais il n’y a même pas une compréhension mutuelle des règles du jeu en cours.

Cette fois, c’est mon beau-père qui a posé la question. Je l’ai aidé à combattre les problèmes de sa machine Windows pendant des années, et il a retenu de nombreuses bonnes pratiques que j’ai essayé de lui transmettre (« ouvre ce genre de courriel et dis adieu à tes données » — ce genre de choses.) Pour expliquer l’open source en général, voilà ce que moi (ainsi que ma femme, par moments) je lui ai dit.

Imagine, ai-je commencé, que tous les logiciels qui tournent sur ton ordinateur sont comme une collection de livres dans une bibliothèque. Certains livres sont neufs, certains sont intéressants, certains ne le sont pas. Mais quels que soient leur sujet, ces livres ont un point commun : ce sont des livres. Ils sont comme ils sont, figés. Les mots inscrits sur les pages sont indélébiles, écrits par les auteurs et ils apparaîtront pour toujours comme ils ont été publiés.

De temps en temps, une nouvelle édition du livre peut paraître, en particulier si le livre est populaire. La nouvelle édition contiendra moins de coquilles et peut-être de l’information mise à jour. D’autres auteurs peuvent faire surface et écrire de nouveaux ouvrages, approfondis par rapport aux best-sellers, en complément. Mais tout au long de ce processus, ces livres sont figés à partir du moment où ils sont publiés.

C’est comme ça, disais-je, que la majorité des logiciels sur ton ordinateur fonctionnent. L’ordinateur peut les lire et les utiliser, mais personne, hormis les auteurs ou les éditeurs des logiciels, ne peut les changer.

Maintenant imagine le contenu de ces livres sur un support moins immuable. Par exemple une série de pages web. Le contenu commence de la même manière que pour les livres papiers, mais il est plus simple et plus rapide d’apporter des changements à ce contenu. Pas besoin de ré-imprimer le livre pour corriger « Appelez-moi Iggy ». Maintenant, ajoute à cela que comme tout peut être facilement modifié, tout le monde a le droit de lire un livre, et d’y apporter des changements. Et chacun de ces livres est gratuit.

C’est cela, lui disais-je, le logiciel open source. Il est installé tel quel, mais (si tu le souhaites), tu peux y apporter les modifications qui répondront à tes besoins. Un manuel rassemblant les instructions de réparation de tous les tracteurs au monde peut être réduit en un seul qui concerne seulement les tracteurs qui t’intéressent. Ou bien tu peux corriger toi-même toutes les fautes que tu trouveras dans le livre.

Puis vint l’inévitable question :

« Donc si tu donnes ces livres gratuitement, comment gagnes-tu de l’argent ? »

Eh bien, ai-je répondu, tu te rappelles les livres complémentaires que j’ai mentionnés ? Pense à eux comme des logiciels dont ton entreprise a besoin pour mener à bien son activité. Pour obtenir des logiciels meilleurs, plus efficaces, tu as besoin de les ajuster au logiciel libre de départ. Et ces ajustements, c’est là le plus important, demandent des compétences.

En effet, même si le logiciel est ouvert, il faut des compétences pour le modifier. De la même manière qu’il en faut pour écrire des livres. Si tu as ces compétences, alors c’est facile : récupérer le logiciel libre, y apporter ses modifications, et c’est parti. Mais ceux qui ont le plus de compétences et de connaissances sont, comme tu t’en doutes, les personnes qui ont écrit ce logiciel en premier lieu. Ainsi elles offriront leur aide à ceux qui en ont besoin. S’il s’agit d’entreprises commerciales, comme Red Hat, SUSE ou Canonical, elles monnaieront leur aide aux clients, ce qui générera un revenu.

Ça a semblé faire tilt.

« Donc toi tu écris les programmes ?»

— Non, étant donné que les gens de la communauté peuvent et vont le faire. Mon travail consiste à rendre le logiciel plus simple à utiliser (comment mieux lire le livre) et à écrire (en aidant à rassembler des procédures et des outils pour écrire des livres plus efficacement). Parce qu’on a besoin d’une certaine forme d’organisation. Donc je trouve des gens intéressés par l’évolution du logiciel et des gens qui trouvent un intérêt à utiliser ce logiciel. Et, comme il y a un intérêt commercial au logiciel, certains me rémunéreront pour faire ça.

De toute évidence, il y a des nuances que je n’ai pas approfondies, comme les licences permissives contre les licences restrictives, la gouvernance et les paramètres. Mais pour le moment, c’est là l’explication la plus efficace que j’ai utilisée pour illustrer l’idée d’open source et de la communauté. Dans cet esprit, n’hésitez pas à l’utiliser ou à l’améliorer.

En mai dernier, sur l’événement « Vosges Opération Libre », j’ai eu la chance d’assister à une conférence de Benjamin Sonntag qui ne m’était pas adressée. Ce défenseur de la culture libre, du chiffrement et de la neutralité du net avait choisi de parler aux barbu-e-s, à ces personnes qui font l’informatique, qui développent nos systèmes d’exploitation, logiciels et services. Son message était simple. Si l’on veut revenir à un « ordinateur ami », celui qui ne se retourne pas contre nous pour aspirer nos données, il faut qu’un maximum de monde utilise des services décentralisés, du chiffrement et du logiciel libre.

Et pour cela, inspirons-nous des succès du logiciel libre. Firefox, VLC, Wikipédia… sont constamment utilisés par les Dupuis-Morizeau, sans que cette sympathique famille-témoin de Normandie n’aille regarder sous le capot. Coder ne suffit pas. Il faut s’efforcer d’impliquer à la source du développement des ergonomistes, des designeurs et des graphistes. Des gens qui rendront l’utilisation du libre décentralisé et chiffré tellement simple qu’elle en deviendra évidente et se répandra comme une trainée de poudre. Des gens qui sauront se mettre à la place de l’utilisateur lambda, d’une Jessica.

L’histoire de Jessica ne nous enseigne pas d’abandonner toute éducation à l’informatique, au Libre et aux sujets qui nous mobilisent. L’histoire de Jessica nous rappelle qu’il y a des personnes qui conduisent sans connaître le fonctionnement d’un moteur à explosion. Et que c’est à nous de ne pas les laisser au bord de la route.

L’histoire de Jessica

Par SwiftOnSecurity (CC-BY 4.0)
Article original paru sur le tumblr de SwiftOnSecurity
Traduction Framalang : audionuma, Penguin, Diab, nilux, Omegax, nilux, lumi, teromene, r0u et les anonymes…

Je veux que vous vous imaginiez quelqu’un pour moi. Son nom est Jessica et elle a 17 ans. Elle vit dans un petit 3 pièces avec sa mère, et elle a un vieil ordinateur portable récupéré d’un ex de sa mère. Elle s’en sert pour se connecter au portail communautaire de son lycée. Elle s’intéresse aux garçons, à l’amour et au versement de la prochaine mensualité du loyer qui permettra à sa mère et elle de garder leur logement.

Elle n’a pas d’argent pour un nouvel ordinateur portable. Elle n’a pas non plus d’argent pour le mettre à niveau. Elle ne sait même pas comment on fait ça. Elle a d’autres centres d’intérêt, comme la biologie. Ce qui l’inquiète, c’est de savoir comment elle va payer ses études à la fac, et si ses résultats seront assez bons pour, d’une manière ou d’une autre, obtenir une bourse.

La seule personne de son entourage qui s’y connaisse en ordinateurs, c’est Josh, du cours d’anglais. Elle sait qu’il lui faut un antivirus, alors c’est à lui qu’elle demande. Il lui en propose un à 50$ par an, mais remarquant son soudain malaise, il mentionne gentiment un antivirus gratuit. Lorsqu’elle rentre à la maison, elle le télécharge et l’installe. Ça lui a demandé des efforts, ça semblait compliqué, ça a pris un peu de temps, mais il y avait maintenant une nouvelle icône rassurante en bas à droite de son écran qui indiquait « Protégé » lorsqu’elle passait sa souris dessus.

Jessica entend constamment aux infos des histoires d’entreprises piratées, de photos volées. Elle a entendu sur CNN qu’il fallait avoir un mot de passe complexe contenant quelque chose de spécial, comme un symbole dollar, alors elle obtempère. Au moins pour son compte Facebook — tout ça ne l’intéresse pas assez pour chercher comment changer les mots de passe de ses autres comptes. Ça semble tellement fastidieux, et elle est déjà assez occupée à retenir les équations abstraites de son cours de maths. Elle n’a pas envie de mémoriser une autre chaîne de caractères abstraite pour ses mots de passe. Et puis, c’est une adolescente ; son cerveau n’est doué ni pour l’organisation, ni pour prévoir et pallier les risques.

Elle a entendu parler d’un truc appelé gestionnaire de mots de passe, mais elle sait qu’il ne faut pas télécharger sur Internet. Elle ne sait pas à qui faire confiance. Une fois, elle a cliqué sur le bouton « Télécharger maintenant » pour un programme dont elle avait entendu parler aux infos, et ça l’a emmenée sur un site différent. Elle n’a pas de communauté à qui demander conseil. Et à côté de ça, elle essaie de trouver quoi porter pour son rendez-vous avec Alex samedi. Jessica se demande s’il l’aimera bien quand il la connaîtra mieux, après avoir passé du temps ensemble et parlé en tête à tête pour la première fois. Elle s’inquiète aussi de savoir s’il va briser son cœur, comme les autres.

Parfois, elle a des fenêtres qui lui demandent de mettre à jour un logiciel. Mais une fois, elle a mis à jour un truc appelé Java, et après avoir cliqué sur le E bleu qui la conduit sur Facebook, une nouvelle ligne d’icônes est apparue. Elle n’est pas sûre que ce soit lié, mais elle est du genre suspicieuse. L’ordinateur fonctionne toujours, et elle ne veut pas le casser en essayant de tirer ça au clair. Elle ne peut pas s’offrir une hotline comme Geek Squad pour 200$. C’est embêtant, mais ça fonctionne toujours. La prochaine fois que quelque chose lui demandera une mise à jour, elle dira non. Elle n’a pas besoin de nouvelles fonctionnalités, surtout si elles rendent sa fenêtre Facebook encore plus petite. Et si c’était important, elles s’installeraient toutes seules, non ? Pourquoi devraient-elles demander ? Il est 19H42, elle doit aller à son rendez-vous.

Un jour, Jessica reçoit un e-mail qui se dit être une lettre d’expulsion. Il dit aussi provenir de communication-locataires@hud.gov. Elle sait ce qu’est HUD, pour l’avoir vu sur les formulaires que sa mère remplit pour bénéficier d’une aide au paiement de l’appartement. Mais elle a entendu aux informations qu’il ne fallait pas ouvrir de fichiers inconnus. Elle s’improvise alors détective. Elle va sur le site hud.gov, et c’est bien ce à quoi elle s’attendait : le Département Américain de l’Habitation et du Développement Urbain. Elle navigue sur le site, qui ne semble pas avoir été écrit par un Russe. Elle ouvre donc le fichier. Adobe Reader s’ouvre, mais le mail dit clairement que si le document est vide, il n’y a pas à s’inquiéter. Elle essaie d’aller à la page suivante, mais il n’y en a pas. Tant pis. Elle n’en parlera pas pas à sa mère, car elle ne veut pas l’inquiéter.

Ce que Jessica ne sait pas, c’est que la lumière blanche qui a commencé à s’allumer sur son ordinateur est celle de la caméra intégrée. Elle ne sait même pas que son ordinateur a une caméra. Mais cette caméra a commencé à l’enregistrer. Et le logiciel qui enregistre sa caméra a aussi commencé à enregistrer tout ce qui s’affiche sur son écran. Y compris quand elle a envoyé à Alex les photos qu’elle a prise pour lui, lorsqu’elle est tombée amoureuse de lui. De toute façon, quand elle entre ses mots de passe, ils s’affichent sous la forme de ronds noirs. Même si quelqu’un était derrière elle et regardait son écran, il ne pourrait pas connaître son mot de passe. Elle ne sait pas que le logiciel enregistre aussi ce qu’elle tape sur son clavier. Rien ne l’a alertée. Tout comme rien ne l’a alertée que la caméra était allumée. Et le microphone.

De temps en temps, elle passe sa souris sur l’icône de l’antivirus. Ça lui dit « protégé ». Ça ne peut qu’être vrai. Après tout c’est le logiciel que Josh lui a conseillé…

Quel est le tort de Jessica dans cette histoire ? Est-ce le fait de ne pas s’être renseignée sur les avantages de l‘Open Source et de ne pas utiliser Linux, qui est gratuit ? Est-ce le fait de ne pas avoir d’amis ou de personnes de sa famille suffisamment calées en informatique et à qui elle pourrait demander conseil ? Est-ce le fait de ne pas s’être liée d’amitié avec Josh ? Est-ce le fait d’avoir d’autres priorités dans la vie ? Est-ce le fait de ne pas savoir que les sociétés qui lui fournissent des mises à jour en profitent pour envahir son ordinateur de logiciels malveillants, et qu’elle doive systématiquement décocher une case pour ne pas les avoir ? Est-ce le fait de ne pas savoir que le protocole SMTP est une vieille technologie qui ne demande pas d’authentification ? Pourquoi n’a-t-elle pas mis de ruban adhésif devant sa webcam ? Pourquoi n’a-t-elle pas démonté son ordinateur pour en retirer le microphone ?

Peut-être que ce n’est pas de sa faute. Peut-être que la sécurité informatique pour les gens normaux n’est pas la série d’étapes faciles et de vérités absolues que nous leur assénons avec notre prétendue sagesse, et qu’ils préfèrent ignorer par mépris pour la sous-classe de nerds que nous sommes.

Peut-être que c’est le fonctionnement même de l’informatique grand public qui en est la cause. Et qui a construit ce monde de libertés, un monde qui a si bien servi à cette Jessica de 17 ans ? C’est vous. C’est nous.

Alors ? À qui la faute ?
***

Crédits photos :

Conférence Benjamin Sonntag : CC-BY-SA Lionel Allorge

Innocent Girl on Laptop : CC-BY-SA Picture Youth

Internet Surveillance : CC-BY Mike Licht.

Voilà des années qu’on nous prédit que l’année suivante sera celle de Linux sur le desktop mais on est encore bien loin de son adoption sur l’ordinateur familial des Dupuis-Morizeau^[1]. D’autant que la ligne de front s’est maintenant déplacée vers les mobiles, les tablettes, les objets connectés…
Le tableau du champ de bataille serait plutôt sombre, le libre et l‘open source peinent à exister parmi les mastodontes qui s’affrontent. Mais voici comme pour nous consoler un petit lambeau de ciel bleu : le bilan que tire Glyn Moody de ce qu’il considère comme la domination victorieuse de l‘open source — Comment ça ? — On comprend mieux quand on remarque que son billet ici traduit est placé dans la rubrique Open Entreprise…

2015 : l’Open Source a gagné, mais ce n’est qu’un début.

Après les succès de 2014, jusqu’où ira-t-elle ?

par Glyn Moody

Article original : 2015: Open Source Has Won, But It Isn’t Finished
Traduction Framalang : Diab, sinma, goofy, AFS, lamessen, KoS, Narcisse, cpio

À l’aube d’une nouvelle année, la tradition veut que l’on fasse une rétrospective des 12 mois précédents. Mais en ce qui concerne cette rubrique, il est facile de résumer ce qui s’est passé : l‘open source a gagné. Reprenons depuis le début :

Les supercalculateurs. L’hégémonie de Linux dans le top 500 des supercalculateurs est telle que c’en est presque gênant. Les chiffres de novembre 2014 montrent que 485 des 500 premiers systèmes tournent sous une version de Linux ou une autre. Un seul d’entre eux tourne sous Windows. C’est encore plus impressionnant si l’on regarde le nombre de cœurs concernés. Là, on retrouve Linux sur 22 581 693 cœurs, tandis que Windows n’en fait tourner que 30 720 ; cela signifie que non seulement Linux domine, mais aussi que sa position est particulièrement forte sur les plus gros systèmes.

L’informatique dans le nuage. La Fondation Linux a proposé l’année dernière un rapport intéressant qui analysait l’utilisation de Linux dans le cloud par les grandes entreprises. Il montrait que 75 % d’entre elles utilisent Linux comme plateforme principale contre 23 % pour Windows. Il est difficile de traduire cela en parts de marché car les solutions hybrides doivent être prises en compte. Toutefois, en raison de la popularité actuelle de l’informatique délocalisée, il est évident que l’on peut considérer que l’utilisation de Linux est importante et croissante. Concrètement, la même étude a montré que le déploiement de Linux dans le cloud était passé de 65 % à 78 % quand Windows chutait de 45 % à 36 %. Bien entendu, certains considéreront que la Fondation Linux n’est pas totalement objective ici, mais malgré cela et compte tenu des incertitudes statistiques, on voit clairement dans quelle direction l’on va.

Les serveurs web. L‘open source domine ce secteur depuis près de 20 ans — une performance. Cependant la répartition des parts de marché à récemment évolué de façon intéressante : à un moment donné, IIS de Microsoft a réussi à dépasser Apache en nombre total de serveurs web, mais, comme l’explique Netcraft dans son analyse la plus récente, il faut y regarder à deux fois :

C’est le second mois d’affilée que l’on enregistre une forte baisse du nombre total de sites web, faisant de ce mois celui qui en totalise le moins depuis janvier. Comme c’était le cas en novembre, ces pertes se sont concentrées sur un nombre limité de sociétés d’hébergement, avec les dix plus fortes baisses qui représentent plus de 52 millions de noms de domaine. Les sites actifs et les ordinateurs visibles sur le web n’ont pas été affectés par ces pertes. Les sites concernés étaient essentiellement des fermes de liens, avec très peu de contenu unique. La majorité de ces sites fonctionnaient avec Microsoft IIS, l’amenant à dépasser Apache dans l’enquête de juillet 2014. Cependant, les récentes pertes ont entraîné une chute de 29.8 % des parts de marché de ce système d’exploitation, qui se situe désormais à plus de 10 points (en pourcentage) derrière Apache.

Ainsi, la « percée » de Microsoft est plus virtuelle que réelle, car elle repose en grande partie sur des sites de liens sans grand contenu utile. Du reste, les chiffres de Netcraft sur les sites actifs brossent un tout autre tableau : Apache aurait 50,57 % des parts de marché, suivi par Nginx avec 14,73 %. Microsoft IIS arriverait péniblement derrière avec un pourcentage assez faible de 11,72 %. Ce qui signifie que l‘open source représente environ 65 % du marché des serveurs Web actifs – pas tout à fait au niveau des supercalculateurs, mais c’est tout de même plutôt bien.

Les systèmes mobiles. Ici, l’avancée de l‘open source, à travers Android, se poursuit. Les derniers chiffres montrent que 83,6 % des smartphones livrés au troisième trimestre 2014 tournent sur Android, en augmentation par rapport aux 81,4 % du même trimestre l’année précédente. Apple baisse, passant de 13,4 % à 12,3 %. Sur le marché des les tablettes, Android suit une trajectoire identique : au second trimestre 2014, Android atteignait environ 75 % des ventes mondiales, alors que celles d’Apple se situaient aux alentours de 25 %.

Les systèmes embarqués. Bien qu’il soit plus difficile de quantifier les parts de marché de Linux sur l’important marché des systèmes embarqués, les chiffres d’une étude de 2013 indiquent qu’environ la moitié des systèmes embarqués utiliseraient ce système d’exploitation.

L’Internet des objets. À plus d’un titre, il s’agit simplement d’un autre avatar des systèmes embarqués, à la différence qu’ils sont conçus pour être connectés en permanence. Il est encore trop tôt pour parler de parts de marché, mais comme je l’ai récemment expliqué, le framework open source AllSeen arrive en tête. Ceux qui brillent par leur absence, de façon frappante, ce sont les concurrents propriétaires crédibles ; il semble extrêmement probable que l’Internet des objets verra l’adoption de l‘open source aux mêmes niveaux que les supercalculateurs.

Bien sûr, un tel niveau de réussite soulève toujours la question : quelle est l’étape suivante ? Étant donné que l‘open source approche de la saturation dans de nombreux secteurs, une baisse est-elle inévitable à l’avenir ? En réponse à cette question, je recommande la lecture d’un essai qui donne à réfléchir, écrit en 2013 par Christopher Kelty pour le Journal of peer production et bizarrement intitulé : « Il n’y a pas de logiciel libre ». Voici comment il débute :

Le logiciel libre n’existe pas. Cela m’attriste étant donné que j’ai écrit un livre entier sur le sujet. Mais il s’agit aussi d’un point que je tente de traiter dans mon livre. Le logiciel libre, et son frère jumeau l‘open source, est en constant devenir. Il n’existe pas sous une forme stable, permanente ni pérenne, et c’est ce qui fait une partie de sa force.

En d’autres termes, 2014 nous a déjà apporté toutes sortes de formidables logiciels libres, mais nous pouvons être sûrs que 2015 nous en apportera bien davantage, car ils poursuivent indéfiniment leur évolution.

Crédit photo
Glyn Moody par Stuart Yeates – (CC BY-SA 2.0)