L’actualité récente de Qwant était mouvementée, mais il nous a semblé qu’au-delà des polémiques c’était le bon moment pour faire le point avec Qwant, ses projets et ses valeurs.

Si comme moi vous étiez un peu distrait⋅e et en étiez resté⋅e à Qwant-le-moteur-de-recherche, vous allez peut-être partager ma surprise : en fouinant un peu, on trouve tout un archipel de services, certains déjà en place et disponibles, d’autres en phase expérimentale, d’autres encore en couveuse dans le labo.

Voyons un peu avec Tristan Nitot, Vice-président Advocacy de Qwant, de quoi il retourne et si le principe affiché de respecter la vie privée des utilisateurs et utilisatrices demeure une ligne directrice pour les applications qui arrivent.

Bonjour Tristan, tu es toujours content de travailler pour Qwant malgré les périodes de turbulence ?
Oui, bien sûr ! Je reviens un peu en arrière : début 2018, j’ai déjeuné avec un ancien collègue de chez Mozilla, David Scravaglieri, qui travaillait chez Qwant. Il m’a parlé de tous les projets en logiciel libre qu’il lançait chez Qwant en tant que directeur de la recherche. C’est ce qui m’a convaincu de postuler chez Qwant.

J’étais déjà fan de l’approche liée au respect de la vie privée et à la volonté de faire un moteur de recherche européen, mais là, en plus, Qwant se préparait à faire du logiciel libre, j’étais conquis. À peine arrivé au dessert, j’envoie un texto au président, Eric Léandri pour savoir quand il m’embauchait. Sa réponse fut immédiate : « Quand tu veux ! ». J’étais aux anges de pouvoir travailler sur des projets qui rassemblent mes deux casquettes, à savoir vie privée et logiciel libre.

Depuis, 18 mois ont passé, les équipes n’ont pas chômé et les premiers produits arrivent en version Alpha puis Bêta. C’est un moment très excitant !

Récemment, Qwant a proposé Maps en version Bêta… Vous comptez vraiment rivaliser avec Google Maps ? Parce que moi j’aime bien Street View par exemple, est-ce que c’est une fonctionnalité qui viendra un jour pour Qwant Maps ?

Rivaliser avec les géants américains du capitalisme de surveillance n’est pas facile, justement parce qu’on cherche un autre modèle, respectueux de la vie privée. En plus, ils ont des budgets incroyables, parce que le capitalisme de surveillance est extrêmement lucratif. Plutôt que d’essayer de trouver des financements comparables, on change les règles du jeu et on se rapproche de l’écosystème libre OpenStreetMap, qu’on pourrait décrire comme le Wikipédia de la donnée géographique. C’est une base de données géographiques contenant des données et des logiciels sous licence libre, créée par des bénévoles autour desquels viennent aussi des entreprises pour former ensemble un écosystème. Qwant fait partie de cet écosystème.
En ce qui concerne les fonctionnalités futures, c’est difficile d’être précis, mais il y a plein de choses que nous pouvons mettre en place grâce à l’écosystème OSM. On a déjà ajouté le calcul d’itinéraires il y a quelques mois, et on pourrait se reposer sur Mapillary pour avoir des images façon StreetView, mais libres !

Dis donc, en comparant 2 cartes du même endroit, on voit que Qwant Maps a encore des progrès à faire en précision ! Pourquoi est-ce que Qwant Maps ne reprend pas l’intégralité d’Open Street Maps ?

En fait, OSM montre énormément de détails et on a choisi d’en avoir un peu moins mais plus utilisables. On a deux sources de données pour les points d’intérêt (POI) : Pages Jaunes, avec qui on a un contrat commercial et OSM. On n’affiche qu’un seul jeu de POI à un instant t, en fonction de ce que tu as recherché.

Quand tu choisis par exemple « Restaurants » ou « Banques », sans le savoir tu fais une recherche sur les POI Pages Jaunes. Donc tu as un fond de carte OSM avec des POI Pages Jaunes, qui sont moins riches que ceux d’OSM mais plus directement lisibles.

Bon d’accord, Qwant Maps utilise les données d’OSM, c’est tant mieux, mais alors vous vampirisez du travail bénévole et libre ? Quelle est la nature du deal avec OSM ?

Non, bien sûr, Qwant n’a pas vocation à vampiriser l’écosystème OSM : nous voulons au contraire être un citoyen modèle d’OSM. Nous utilisons les données et logiciels d’OSM conformément à leur licence. Il n’y a donc pas vraiment de deal, juste un respect des licences dans la forme et dans l’esprit. Par exemple, on met un lien qui propose aux utilisateurs de Qwant Maps d’apprendre à utiliser et contribuer à OSM. En ce qui concerne les logiciels libres nécessaires au fonctionnement d’OSM, on les utilise et on y contribue, par exemple avec les projets Mimirsbrunn, Kartotherian et Idunn. Mes collègues ont écrit un billet de blog à ce sujet.

Nous avons aussi participé à la réunion annuelle d’OSM, State Of the Map (SOTM) à Montpellier le 14 juin dernier, où j’étais invité à parler justement des relations entre les entreprises comme Qwant et les projets libres de communs numériques comme OSM. Les mauvais exemples ne manquent pas, avec Apple qui, avec Safari et Webkit, a sabordé le projet Konqueror de navigateur libre, ou Google qui reprend de la data de Wikipédia mais ne met pas de lien sur comment y contribuer (alors que Qwant le fait). Chez Qwant, on vise à être en symbiose avec les projets libres qu’on utilise et auxquels on contribue.

Google Maps a commencé à monétiser les emplois de sa cartographie, est-ce qu’un jour Qwant Maps va être payant ?

En réalité, Google Maps est toujours gratuit pour les particuliers (approche B2C Business to consumer). Pour les organisations ou entreprises qui veulent mettre une carte sur leur site web (modèle B2B Business to business), Google Maps a longtemps été gratuit avant de devenir brutalement payant, une fois qu’il a éliminé tous ses concurrents commerciaux. Il apparaît assez clairement que Google a fait preuve de dumping.

Pour le moment, chez Qwant, il n’y a pas d’offre B2B. Le jour où il y en aura une, j’espère que le un coût associé sera beaucoup plus raisonnable que chez Google, qui prend vraiment ses clients pour des vaches à lait. Je comprends qu’il faille financer le service qui a un coût, mais là, c’est exagéré !

Quand j’utilise Qwant Maps, est-ce que je suis pisté par des traqueurs ? J’imagine et j’espère que non, mais qu’est-ce que Qwant Maps « récolte » et « garde » de moi et de ma connexion si je lui demande où se trouve Bure avec ses opposants à l’enfouissement de déchets nucléaires ? Quelles garanties m’offre Qwant Maps de la confidentialité de mes recherches en cartographie ?

C’est un principe fort chez Qwant : on ne veut pas collecter de données personnelles. Bien sûr, à un instant donné, le serveur doit disposer à la fois de la requête (quelle zone de la carte est demandée, à quelle échelle) et l’adresse IP qui la demande. L’adresse IP pourrait permettre de retrouver qui fait quelle recherche, et Qwant veut empêcher cela. C’est pourquoi l’adresse IP est salée  et hachée  aussitôt que possible et c’est le résultat qui est stocké. Ainsi, il est impossible de faire machine arrière et de retrouver quelle adresse IP a fait quelle recherche sur la carte. C’est cette méthode qui est utilisée dans Qwant Search pour empêcher de savoir qui a recherché quoi dans le moteur de recherche.

Est-ce que ça veut dire qu’on perd aussi le relatif confort d’avoir un historique utile de ses recherches cartographiques ou générales ? Si je veux gagner en confidentialité, j’accepte de perdre en confort ?
Effectivement, Qwant ne veut rien savoir sur la personne qui recherche, ce qui implique qu’on ne peut pas personnaliser les résultats, ni au niveau des recherches Web ni au niveau cartographique : pour une recherche donnée, chaque utilisateur reçoit les mêmes résultats que tout le monde.

Ça peut être un problème pour certaines personnes, qui aimeraient bien disposer de personnalisation. Mais Qwant n’a pas dit son dernier mot : c’est exactement pour ça que nous avons fait « Masq by Qwant ». Masq, c’est une application Web en logiciel libre qui permet de stocker localement dans le navigateur (en LocalStorage)¹ et de façon chiffrée des données pour la personnalisation de l’expérience utilisateur. Masq est encore en Alpha et il ne permet pour l’instant que de stocker (localement !) ses favoris cartographiques. À terme, nous voulons que les différents services de Qwant utilisent Masq pour faire de la personnalisation respectueuse de la vie privée.

Ah bon alors c’est fini le cloud, on met tout sur sa machine locale ? Et si on vient fouiner dans mon appareil alors ? N’importe quel intrus peut voir mes données personnelles stockées ?

Effectivement, tes données étant chiffrées, et comme tu es le seul à disposer du mot de passe, c’est ta responsabilité de conserver précieusement ledit mot de passe. Quant à la sauvegarde des données, tu as bien pensé à faire une sauvegarde, non ? 😉

Ah mais vous avez aussi un projet de reconnaissance d’images ? Comment ça marche ? Et à quoi ça peut être utile ?
C’est le résultat du travail de chercheurs de Qwant Research, une intelligence artificielle (plus concrètement un réseau de neurones) qu’on a entraînée avec Pytorch sur des serveurs spécialisés DGX-1 en vue de proposer des images similaires à celles que tu décris ou que tu téléverses.

 Ah tiens j’ai essayé un peu, ça donne effectivement des résultats rigolos : si on cherche des saucisses, on a aussi des carottes, des crevettes et des dents…

C’est encore imparfait comme tu le soulignes, et c’est bien pour ça que ça n’est pas encore un produit en production ! On compte utiliser cette technologie de pointe pour la future version de notre moteur de recherche d’images.

Comment je fais pour signaler à l’IA qu’elle s’est plantée sur telle ou telle image ? C’est prévu de faire collaborer les bêta-testeurs ? Est-ce que Qwant accueille les contributions bénévoles ou militantes ?
Il est prévu d’ajouter un bouton pour que les utilisateurs puissent valider ou invalider une image par rapport à une description. Pour des projets de plus en plus nombreux, Qwant produit du logiciel libre et donc publie le code. Par exemple pour la recherche d’image, c’est sur https://github.com/QwantResearch/text-image-similarity. Les autres projets sont hébergés sur les dépôts https://github.com/QwantResearch : les contributions au code (Pull requests) et les descriptions de bugs (issues) sont les bienvenus !

Bon je vois que Qwant a l’ambition de couvrir autant de domaines que Google ? C’est pas un peu hégémonique tout ça ? On se croirait dans Dégooglisons Internet !

• Qwant Music (depuis juin 2016)
• Boards, des « carnets » personnels en ligne
• Qwant Junior
• et encore ce projet-là parmi d’autres…

Effectivement, nos utilisateurs attendent de Qwant tout un univers de services. La recherche est pour nous une tête de pont, mais on travaille à de nouveaux services. Certains sont des moteurs de recherche spécialisés comme Qwant Junior, pour les enfants de 6 à 12 ans (pas de pornographie, de drogues, d’incitation à la haine ou à la violence).

Comment c’est calculé, les épineuses questions de résultats de recherche ou non avec Qwant Junior ? Ça doit être compliqué de filtrer…

Nous avons des équipes qui gèrent cela et s’assurent que les sujets sont abordables par les enfants de 6 à 12 ans, qui sont notre cible pour Junior.
Ça n’est pas facile effectivement, mais nous pensons que c’est important. C’est une idée qui nous est venue au lendemain des attentats du Bataclan où trop d’images choquantes étaient publiées par les moteurs de recherche. C’était insupportable pour les enfants. Et puis Junior, comme je le disais, n’a pas vocation à afficher de publicité ni à capturer de données personnelles. C’est aussi pour cela que Qwant Junior est très utilisé dans les écoles, où il donne visiblement satisfaction aux enseignants et enseignantes.

Mais euh… « filtrer » les résultats, c’est le job d’un moteur de recherche ?

Il y a deux questions en fait. Pour un moteur de recherche pour enfants, ça me parait légitime de proposer aux parents un moteur qui ne propose pas de contenus choquants. Qwant Junior n’a pas vocation à être neutre : c’est un service éditorialisé qui fait remonter des contenus à valeur pédagogique pour les enfants. C’est aux parents de décider s’ils l’utilisent ou pas.
Pour un moteur de recherche généraliste revanche, la question est plutôt d’être neutre dans l’affichage des résultats, dans les limites de la loi.

Tiens vous avez même des trucs comme Causes qui propose de reverser l’argent des clics publicitaires à de bonnes causes ? Pour cela il faut désactiver les bloqueurs de pub auxquels nous sommes si attachés, ça va pas plaire aux antipubs…

En ce qui concerne Qwant Causes, c’est le moteur de recherche Qwant mais avec un peu plus de publicité. Et quand tu cliques dessus, cela rapporte de l’argent qui est donné à des associations que tu choisis. C’est une façon de donner à ces associations en faisant des recherches. Bien sûr si tu veux utiliser un bloqueur de pub, c’est autorisé chez Qwant, mais ça n’a pas de sens pour Qwant Causes, c’est pour ça qu’un message d’explication est affiché.

Est-ce que tous ces services sont là pour durer ou bien seront-ils fermés au bout d’un moment s’ils sont trop peu employés, pas rentables, etc. ?

Tous les services n’ont pas vocation à être rentables. Par exemple, il n’y a pas de pub sur Qwant Junior, parce que les enfants y sont déjà trop exposés. Mais Qwant reste une entreprise qui a vocation à générer de l’argent et à rémunérer ses actionnaires, donc la rentabilité est pour elle une chose importante. Et il y a encore de la marge pour concurrencer les dizaines de services proposés par Framasoft et les CHATONS 😉

Est-ce que Qwant est capable de dire combien de personnes utilisent ses services ? Qwant publie-t-elle des statistiques de fréquentation ?
Non. D’abord, on n’identifie pas nos utilisateurs, donc c’est impossible de les compter : on peut compter le nombre de recherches qui sont faites, mais pas par combien de personnes. Et c’est très bien comme ça ! Tout ce que je peux dire, c’est que le nombre de requêtes évolue très rapidement : on fait le point en comité de direction chaque semaine, et nous battons presque à chaque fois un nouveau record !

Bon venons-en aux questions que se posent souvent nos lecteurs et lectrices : Qwant et ses multiples services, c’est libre, open source, ça dépend ?

Non, tout n’est pas en logiciel libre chez Qwant, mais si tu vas sur les dépôts de Qwant et Qwant Research tu verras qu’il y a déjà plein de choses qui sont sous licence libre, y compris des choses stratégiques comme Graphee (calcul de graphe du Web) ou Mermoz (robot d’indexation du moteur). Et puis les nouveaux projets comme Qwant Maps et Masq y sont aussi.

La publicité est une source de revenus dans votre modèle économique, ou bien vous vendez des services à des entreprises ou institutions ? Qwant renonce à un modèle économique lucratif qui a fait les choux gras de Google, mais alors comment gagner de l’argent ?
Oui, Qwant facture aussi des services à des institutions dans le domaine de l’open data par exemple, mais l’essentiel du revenu vient de la publicité contextuelle, à ne pas confondre avec la publicité ciblée telle que faite par les géants américains du Web. C’est très différent.
La publicité ciblée, c’est quand tu sais tout de la personne (ses goûts, ses habitudes, ses déplacements, ses amis, son niveau de revenu, ses recherches web, son historique de navigation, et d’autres choses bien plus indiscrètes telles que ses opinions politiques, son orientation sexuelle ou religieuse, etc.). Alors tu vends à des annonceurs le droit de toucher avec de la pub des personnes qui sont ciblées. C’est le modèle des géants américains.
Qwant, pour sa part, ne veut pas collecter de données personnelles venant de ses utilisateurs. Tu as sûrement remarqué que quand tu vas sur Qwant.com la première fois, il n’y a pas de bannière « acceptez nos cookies ». C’est normal, nous ne déposons pas de cookies quand tu fais une recherche Qwant !

Quand tu fais une recherche, Qwant te donne une réponse qui est la même pour tout le monde. Tu fais une recherche sur « Soupe à la tomate » ? On te donne les résultats et en même temps on voit avec les annonceurs qui est intéressé par ces mots-clés. On ignore tout de toi, ton identité ou ton niveau de revenu. Tout ce qu’on sait, c’est que tu as cherché « soupe à la tomate ». Et c’est ainsi que tu te retrouves avec de la pub pour du Gaspacho ou des ustensiles de cuisine. La publicité vaut un peu moins cher que chez nos concurrents, mais les gens cliquent dessus plus souvent. Au final, ça permet de financer les services et d’en inventer de nouveaux tout en respectant la vie privée des utilisateurs et de proposer une alternative aux services américains gourmands en données personnelles. On pourrait croire que ça ne rapporte pas assez, pourtant c’était le modèle commercial de Google jusqu’en 2006, où il a basculé dans la collecte massive de données personnelles…

Dans quelle mesure Qwant s’inscrit-il dans la reconquête de la souveraineté européenne contre la domination des géants US du Web ?
Effectivement, parmi les deux choses qui différencient Qwant de ses concurrents, il y a la non-collecte de données personnelles et le fait qu’il est français et à vocation européenne. Il y a un truc qui me dérange terriblement dans le numérique actuel, c’est que l’Europe est en train de devenir une colonie numérique des USA et peut-être à terme de la Chine. Or, le numérique est essentiel dans nos vies. Il les transforme ! Ces outils ne sont pas neutres, ils sont le reflet des valeurs de ceux qui les produisent.

Aux USA, les gens sont considérés comme des consommateurs : tout est à vendre à ou à acheter. En Europe, c’est différent. Ça n’est pas un hasard si la CNIL est née en France, si le RGPD est européen : on a conscience de l’enjeu des données personnelles sur la citoyenneté, sur la liberté des gens. Pour moi, que Qwant soit européen, c’est très important.

Merci d’avoir accepté de répondre à nos questions. Comme c’est la tradition de nos interviews, on te laisse le mot de la fin…

Je soutiens Framasoft depuis toujours ou presque, parce que je sais que ce qui y est fait est vraiment important : plus de libre, moins d’hégémonie des suspects habituels, plus de logiciel libre, plus de valeur dans les services proposés.
J’ai l’impression d’avoir avec Qwant une organisation différente par nature (c’est une société, avec des actionnaires), mais avec des objectifs finalement assez proches : fournir des services éthiques, respectueux de la vie pivée, plus proches des gens et de leurs valeurs, tout en contribuant au logiciel libre. C’est ce que j’ai tenté de faire chez Mozilla pendant 17 ans, et maintenant chez Qwant. Alors, je sais que toutes les organisations ne sont pas parfaites, et Qwant ne fait pas exception à la règle. En tout cas, chez Qwant on fait du mieux qu’on peut !

Vive l’Internet libre et ceux qui œuvrent à le mettre en place et à le défendre !

Le projet de réforme du droit d’auteur provoque une forte inquiétude au sein des communautés de développeurs et développeuses de logiciels libres. Que restera-t-il de leur liberté de partager et modifier si obligation est faite aux forges logicielles de mettre en place des filtres de contenus ? L’eurodéputée Julia Reda nous indique les façons dont nous pouvons tous agir, dès maintenant.

« Les machines à censurer arrivent : il est temps que la communauté du logiciel libre prenne conscience de son impact politique »

Source : article rédigé par l’eurodéputée Julia Reda et publié sur son site le 6 avril 2018

Traduction initialement publiée par l’April : Guestr, Alain Mille, etienne, mmu_man, tierce, Vanecx, mo, MicroCheapFx, freepoet, yannicka, Fred.

Le développement du logiciel libre tel que nous le connaissons est menacé par les projets de réforme du droit d’auteur de l’Union européenne.

La bataille continue autour de la proposition de réforme du droit d’auteur dans l’UE, se concentrant autour du projet de filtrer les contenus au moment de leur téléversement (en anglais). En résumé, on demanderait aux plateformes en ligne de contrôler les contenus chargés par leurs utilisateurs et utilisatrices afin de tenter de prévenir les violations du droit d’auteur par des filtres automatiques. Puisque la plupart des communications en ligne consistent en un dépôt de fichiers sur différentes plateformes, de telles « machines à censurer » auraient de larges conséquences, y compris pour les dépôts de logiciels libres et open source.

Sur ces plateformes, des développeurs et développeuses du monde entier travaillent de concert sur des projets de logiciels que quiconque peut librement utiliser et adapter. À coup sûr, ces filtres automatiques feraient état de nombreux faux-positifs. La suppression automatique de contenus signifierait que les personnes ayant contribué seraient présumées coupables jusqu’à prouver leur innocence : des contributions légitimes se verraient bloquées.

Les récentes levées de boucliers à ce sujet au sein de la communauté du logiciel libre/open-source commencent à porter leurs fruits : nos préoccupations sont en train d’attirer l’attention des porteurs de lois. Malheureusement cependant, la plupart comprennent mal les enjeux et tirent de mauvaises conclusions. Maintenant que nous savons quelle est la force de la voix de la communauté, il est d’autant plus important de continuer à la faire entendre !

Pourquoi cela ?

Le point de départ de cette législation a été une bataille entre de grosses entreprises, l’industrie musicale et YouTube, à propos d’argent. L’industrie musicale s’est plainte de moins percevoir chaque fois qu’un morceau de leur catalogue est joué sur une plateforme vidéo comme YouTube que lorsqu’il est diffusé sur des services d’abonnement comme Spotify, qualifiant la différence de « manque-à-gagner ». Elle s’est alors lancée, avec succès, dans une campagne de lobbying : la loi sur le filtrage des contenus vise principalement à lui donner un atout afin de demander plus d’argent à Google au moment des négociations. Pendant ce temps, toutes les autres plateformes se retrouvent au milieu de cette bagarre, y compris les communautés de partage de code.

Le lobbying a ancré dans l’esprit de nombreux législateurs la fausse idée que les plateformes d’hébergement à but lucratif exploitent nécessairement les créateurs et créatrices.

Partage de code

Il y a cependant beaucoup d’exemples où il existe une relation symbiotique entre la plateforme et les créateurs et créatrices. Les développeurs et développeuses utilisent et versent volontairement dans les dépôts logiciels parce que les plateformes ajoutent de la valeur. GitHub est une société à but lucratif qui soutient des projets sans but lucratif – elle finance l’hébergement gratuit de projets libres et open source en facturant l’utilisation commerciale des services du site. Ainsi, des travaux libres et open source seront affectés par une loi destinée à réguler un différend entre quelques grandes sociétés.

Dans un récent billet (en anglais), GitHub a tiré la sonnette d’alarme, indiquant trois raisons pour lesquelles le filtrage automatique des contenus constitue une terrible attaque contre les forges logicielles :

1. la loi impose que le code soit filtré parce qu’il est soumis au droit d’auteur – mais de nombreux développeurs et développeuses souhaitent que leur code source soit partagé sous une licence libre et open source ;
2. le risque de faux positifs est très élevé parce que les différentes parties d’un logiciel peuvent être soumises à des licences différentes, ce qui est très difficile à traiter de manière automatisée ;
3. le fait de supprimer automatiquement un code suspecté de porter atteinte au droit d’auteur peut avoir des conséquences désastreuses pour les développeurs et développeuses de logiciels qui s’appuient sur des ressources communes risquant de disparaître à tout moment.

Les inquiétudes commencent à être entendues

Dans sa dernière proposition, le Conseil de l’Union européenne cherche à exclure « les plateformes de développement open source à but non lucratif » de l’obligation de filtrer les contenus chargés par les utilisateurs et utilisatrices. Cet amendement est la conséquence directe de la levée de boucliers par la communauté FLOSS. Cependant, cette exception ne couvre pas les plateformes à but lucratif comme GitHub et bien d’autres, même si une partie seulement de leur activité est à but lucratif.

Plutôt que de remettre en cause le principe de base de la loi, les politiciens essayent d’étouffer les critiques en proposant de plus en plus d’exceptions à celles et ceux qui peuvent démontrer de façon crédible que la loi va les affecter négativement. Créer une telle liste d’exceptions est une tâche titanesque vouée à rester inachevée. Le filtrage des contenus devrait être rejeté dans son ensemble car c’est une mesure disproportionnée mettant en danger le droit fondamental de la liberté d’expression en ligne.

Nous pouvons y arriver !

Pour y parvenir, nous avons besoin de votre aide. La communauté FLOSS ne peut pas résoudre ces problèmes simplement avec du code : elle a un impact politique, la force du nombre et des allié⋅e⋅s au Parlement (européen). Nous avons déjà provoqué certains changements. Voici comment vous pouvez agir dès maintenant :

1. signez la lettre ouverte sur SaveCodeShare (Note de traduction : en anglais, voir l’article de l’April qui soutient cette campagne) ;
2. utilisez l’outil gratuit de Mozilla pour appeler les membres du Parlement européen ;
3. tweetez aux principaux acteurs de la Commission des affaires légales du Parlement européen via FixCopyright (en anglais).

Note technique :

Trois acteurs sont impliqués dans le processus législatif. La Commission émet une première proposition de loi, à laquelle le Parlement européen et le Conseil de l’Union européenne peuvent proposer des amendements. Au sein du Parlement, la loi est d’abord discutée en Commission des affaires légales dans laquelle chaque groupe politique nomme un négociateur. Une fois que la Commission aura voté le compromis élaboré par les négociateurs, le texte sera soumis au vote en séance plénière du Parlement, avant que les négociations ne commencent avec les autres institutions. Le parcours législatif exact est disponible ici (en anglais).

Dans la mesure du possible et conformément à la loi, l’auteur [Julia Reda] renonce à tous les droits d’auteur et droits voisins sur ce texte.

La techno ça sert à rien si ça change pas la vie des gens.

Voici les prénoms des CoopCycle qui nous ont répondu : Alexandre, Aurélien, Aloïs, Antoine, Basile, Jérôme, Kevin, Laury-Anne, Liova, Lison, Paul, Pauline, Vincent.

D’habitude on demande à nos interviewés de se présenter mais je vois bien que vous avez depuis quelques mois une sacrée visibilité médiatique et c’est tant mieux…

Coopcycle – L’explosion médiatique est détaillée sur notre blog Médiapart en toute transparence. Effectivement, ça a explosé au mois d’août en parallèle des rassemblements de livreurs suite au changement de tarification de Deliveroo. Non seulement les journaux ont beaucoup parlé de ces « cyber-grèves » (des travailleurs numériques qui appellent à la déconnexion, ou qui vont empêcher l’utilisation d’un iPad dans un restaurant, c’est original), mais en plus tous étaient unanimes pour condamner le modèle des plateformes.

Tout le monde a entendu parler de votre initiative et s’y intéresse, pourquoi à votre avis ? 

– L’intérêt pour notre initiative vient à notre avis de l’attente qui existait face à un manque d’alternatives permettant de lutter contre une ubérisation de la société parfois perçue comme une fatalité. Le modèle qui se généralise, c’est l’individu auto-entrepreneur dans la « gig economy », l’économie des petits boulots. Face à des plateformes dotées de très gros moyens, tout le monde est un peu les bras ballants, les pouvoirs publics en tête, qui ont même tendance à encourager, « sécuriser » le modèle des plateformes : en penchant pour une jurisprudence qui empêche la requalification des contrats précaires en contrats salariés, en encourageant la délégation de service public, ou en réduisant les normes sur les activités classiques pour leur permettre de faire face à la concurrence à moindre coût des plateformes…

En somme, les pouvoirs publics semblent accompagner l’ubérisation (comme le développe le Conseil d’État au sein de ce document), et accepter le dumping et la casse sociale que ces modèles impliquent, tandis que les livreurs, les restaurateurs et les clients se débrouillent avec une évolution qui semble être un fait accompli.
De plus en plus de monde prend conscience que c’est l’ensemble des régimes de protection sociale qui sont menacés, et personne ne savait comment faire pour répondre à ces problématiques.
Notre initiative cristallise donc beaucoup d’espoirs car c’est une proposition positive, mais qui soulève des problématiques structurelles et interroge la possibilité d’une économie des Communs. En tout cas, ce n’est pas une énième réaction de critique passive à une logique que l’on ne serait pas en position de ralentir ou contrecarrer aujourd’hui. Nous pensons qu’une alternative est possible, et nous allons plus loin en concrétisant nos idées. Dans le débat tel qu’il existe aujourd’hui, c’est déjà une perspective séduisante.

À cause de Nuit Debout ? C’est là que tout a commencé ? À cause des conflits sociaux autour de Deliveroo et autres starteupes qui font tourner les jambes des livreurs pour des rémunérations de misère ?

– Ce n’est pas « à cause de Nuit Debout », c’est plutôt « grâce à Nuit Debout » !
Selon nous, c’est plus la possibilité d’une alternative qui intéresse les gens. Le fait que le projet « vienne de » Nuit Debout, la plupart des gens ne le savent pas.
Mais effectivement ce projet n’existerait pas sans Nuit Debout. C’est un des rares événements politiques qui a eu lieu ces dernières années en France, et même si tout ça paraît déjà lointain, il a suscité une vague d’espoir.

Ce qui nous a réunis sur la place de la République, c’est la lutte contre la loi El Khomri et la précarisation de nos conditions de travail. À partir de là, on se retrouve à participer aux manifestations, on rencontre le Collectif des Livreurs Autonomes de Paris alors que l’idée n’était encore qu’une idée… C’est ce qui a permis l’émergence de groupes de personnes engagées, militantes ou non, qui cherchent des solutions, mènent des campagnes, montent des projets ensemble. Et un de ces projets, c’est CoopCycle.

Elle est destinée à qui cette plateforme en cours de réalisation ? Aux livreurs à vélo, aux restaurateurs, aux consommateurs qui se font livrer ?

– La plateforme est destinée avant tout aux livreurs et aux commerçants, c’est un outil d’émancipation. Les collectivités territoriales ont également une place dans ce genre dispositif car cela leur permet de reprendre le contrôle sur l’espace public ainsi que sur les modes de vivre ensemble.

Mais au final, la plateforme en version « communs » est là pour servir à tout le monde, et pour outiller tout le monde. Quant aux clients finaux, nous sommes persuadés que beaucoup de consommateurs seraient prêts à payer un peu plus cher pour que les livreurs aient de bonnes conditions de travail.

Regardez l’engouement pour les Biocoop, regardez aussi la réussite d’Enercoop, qui fournit de l’énergie durable. À leurs débuts, ces derniers étaient 50 % plus chers que l’opérateur historique et pourtant, ils ont réussi à séduire des clients conscients, qui veulent consommer autrement.

Pour la livraison de repas à domicile, qu’on soit client ou restaurateur, on peut très bien vouloir consommer et commercer de façon éthique et équitable, mais si les seuls outils disponibles sont ceux des capitalistes, on se retrouve à consommer et travailler au profit du capitalisme, qu’on le veuille ou non.
CoopCycle est donc une initiative de reprise en main de la logique des plateformes afin de permettre un rééquilibrage du rapport de force en faveur des livreurs et des restaurateurs dans le secteur de la livraison.

C’est quoi cette licence bizarre que vous avez exhumée des tréfonds du web ? pourquoi celle-là plutôt que d’autres parmi les nombreuses licences libres ?
— La licence qui encadre l’application que nous développons restreint l’utilisation à des groupes de livreurs qui se lancent en coopérative ou respectent des critères de réciprocité. Le fait que dans ce cadre son utilisation serait gratuite fait que la marge qu’ils peuvent proposer aux restaurateurs peut être largement moindre que celle des plateformes capitalistes. Si les livreurs ne veulent pas adhérer à la SCIC nationale sur laquelle nous travaillons ils pourront également y avoir accès.

Néanmoins, cette licence n’est pas parfaite ! Premièrement car nous ne savons pas concrètement comment elle est reconnue et s’inscrit à l’échelle de la France ou plus largement à l’échelle européenne. Plus largement, le respect et la défense des licences est difficile à réellement mettre en œuvre dans le cadre de l’économie numérique. Comment pourrions-nous réellement prouver qu’une entité lucrative privée, fermée par nature, utilise des bouts d’un code développé par le travail Commun ? La problématique est la même dans le cadre d’une utilisation propriétaire du code source. Car une fois la captation identifiée, comment pourrions-nous financer les frais judiciaires qu’un procès impliquerait et qui resteraient à notre charge ?

Enfin ce type de licence ne permet pas l’élaboration d’une cotisation qui permettrait de rémunérer le travail à l’origine de ce Commun. Dès lors, aucun retour de la valeur économique produite ne pourrait être assuré aux contributeurs d’un commun dans la mesure ou ce dernier n’a ni périmètre juridique clairement établi, ni force d’opposition face à un grand groupe. Le cadre légal doit être repensé et c’est toutes ces questions que nous souhaitons traiter au cours des conférences suivantes du cycle que nous avons lancé le 20 septembre.

Et au fait pourquoi open source et pas « libre » ?

Le code n’est pas libre car s’il l’était, n’importe qui pourrait se le réapproprier et l’utiliser pour faire du profit. Aujourd’hui dans le libre, c’est souvent la loi du plus fort qui l’emporte, avec toutes les conséquences que l’on connaît. Il faut donc une licence qui permet de protéger l’utilisation de ce code pour la réserver aux coopératives qui ne veulent pas exploiter les gens. Nous savons qu’il faut travailler sur cette histoire de licence et nous sommes en contact avec des avocats spécialisés sur le sujet. D’ailleurs, si vous en connaissez, on les accueille avec plaisir !

Dans ce monde, on est malheureusement toujours ramené au célèbre « there is no alternative » prononcé par Margaret Thatcher. Il faut être « pragmatique», à savoir accepter les règles du jeu capitaliste, pour que rien ne change.

Aujourd’hui, on voit des gens qui «travaillent » sur des alternatives à Uber, par exemple. Pour certains, le premier réflexe, c’est de vérifier que leur modèle peut avoir des retombées commerciales, qu’ils peuvent financer leur développement avant même d’avoir produit une seule ligne de code…
Ça n’est certainement pas notre approche. You don’t need to know how to do it, you just need to start comme dirait l’autre sur un article Medium.
À l’heure où les plateformes représentent une source non négligeable d’emplois (précaires), l’open source offre une vraie possibilité d’implémenter enfin la copropriété d’usage de l’outil de travail.
Mais il faut des règles pour garantir que l’essentiel de la valeur créée aille aux travailleurs, afin de poursuivre sur le chemin de l’émancipation. Sinon, ce seront forcément ceux qui auront les capitaux qui pourront enclencher les effets de réseau, tout ça en utilisant du « travail gratuit ».
Il est temps d’en finir avec le solutionnisme technologique, il faut ajouter une dimension sociale, sans quoi on retombe dans l’aliénation.

Votre projet n’est donc pas simplement de développer une plateforme informatique, aussi open source soit-elle, c’est aussi un tout autre modèle social, celui de la coopérative. C’est possible de nous expliquer ça simplement ?

Nous n’avons pas envie de créer une startup de l’économie sociale et solidaire. Ce qui nous intéresse, c’est justement le projet politique. Il existe aujourd’hui tout un archipel de sites et d’initiatives qui espèrent « changer le monde » et pourtant, rien de bouge vraiment au niveau macro-économique. Les structures qui permettent l’exploitation des travailleurs sont toujours bien en place. Nous aimerions « secouer le cocotier », et faire du lobbying citoyen pour essayer de modifier ces structures. Certes, nous n’avons pas encore une loi anti-ubérisation dans nos cartons, mais réunir des gens de différents milieux permet de faire réfléchir, de rassembler et à terme d’influencer le jeu politique.

Sur le choix de la coopérative, il s’est assez simplement imposé à nous. Nous sommes en passe d’avoir ce bel outil numérique mais sommes conscients que face aux géants de la foodtech et malgré la surmédiatisation ponctuelle, il ne suffira pas de dire « voici le moyen de vous réapproprier votre outil de travail, à vous de jouer ».

La question qui se pose à nous est celle de l’articulation entre une ressource que l’on gère comme un commun et un circuit économique composé de coopératives qui permettent une rémunération et des conditions de travail correctes pour ceux qui y travaillent. La forme coopérative nous semble la plus adaptée puisqu’elle permet des règles économiques et démocratiques plus équitables (statut salarié, intégration de l’ensemble des acquis sociaux y afférant, mutualisation des moyens comme des risques, une personne une voix, etc.).

Mais nous ne sommes pas dupes évidemment, le développement de ces modèles « sociaux et solidaires » est un mouvement positif, témoignant d’une certaine prise de conscience nécessaire mais non suffisante. La création de structures privées socialisées dans un marché libéral combat le capitalisme sur ses terres mais n’emporte pas de sortie réelle de ce système. Pire encore, on peut également considérer que ce développement parallèle organise le désengagement de l’état in fine, puisque la mutualisation se réorganise à plus petite échelle.

C’est pour cela que nous tenons à agir sur les 3 plans :

• développer un outil open source et libre d’accès sous condition, pour créer l’outil de travail ;
• construire une structure coopérative nationale et des structures locales pour organiser les moyens du travail ;
• questionner les problématiques macro-économiques et structurelles qui se posent aux différentes étapes de notre construction à travers des cycles de conférences thématiques.

Bon alors où en est-il ce code open source de plateforme ?  Vous êtes combien là-derrière ? Vous auriez peut-être besoin d’un coup de main, de patches, de bêta-testeurs, de pintes de bières, enfin tous les trucs qu’on s’échange dans le petit monde du logiciel libre. C’est le moment de lancer un appel à contributions hein…

Notre code est sur GitHub : https://github.com/coopcycle

Pour l’instant il y a 3 personnes qui ont contribué. Notre but est de construire une communauté autour du code, pour assurer la pérennité du projet notamment. On a posé les premiers jalons avec des règles de contribution et une installation en local facile (crash testée !). Nous avons reçu plusieurs propositions spontanées d’aide, mais cherchons encore à voir comment intégrer chacun suivant son temps disponible et ses langages de prédilection. De même nous devons établir une roadmap claire pour le projet. Tout cela explique que nous n’ayons pas encore fait d’appel à contribution.
En tout cas tous les repos ont des issues ouvertes, et n’attendent que vous !
Le feedback sur la démo (UI/UX ou bugs) est plus que bienvenu. Vous pouvez contacter l’équipe dev à dev@coopcycle.org.

Toutefois il ne faut pas résumer notre approche au groupe de développeurs, nous sommes une bonne quinzaine à travailler sur ce projet ; journalisme, portage politique, propagande, représentation, construction du modèle économique, lien avec les livreurs et les restaurateurs. Tous ces travaux sont complémentaires et nous essayons justement de ne pas tomber dans le solutionnisme de l’outil en assumant toutes ces tâches collectivement.

On vous laisse le mot de la fin, comme de coutume sur le Framablog !

Merci pour tous vos outils, c’est un plaisir de pouvoir bâtir son projet avec des logiciels libres ! En attente de Framameet pour nos apéros devs 🙂

57 lignes de code et deux ou trois bidules électroniques feraient aussi bien voire mieux qu’un gros système coûteux. Telle est la démonstration que vient de faire un développeur australien.
L’expérience que relate ici Tait Brown relève du proof of concept, la démonstration de faisabilité. La spectaculaire économie de moyens numériques et financiers qu’il démontre avec 57 lignes de code open source et des appareils à la portée d’un bidouilleur ordinaire n’est peut-être pas une solution adaptable à grande échelle pour remplacer les puissants et massifs systèmes propriétaires mis en place par des entreprises. Pas plus que les services libres de Framasoft n’ambitionnent de remplacer les GAFAM, mais démontrent que des solutions alternatives libres et plus respectueuses sont possibles et viables, et de plus en plus disponibles.

Outre le pied de nez réjouissant du hacker occasionnel aux institutions locales (ici, la police de l’état australien de Victoria) qui ont confié un traitement informatique à des sociétés privées, ce petit témoignage ouvre au moins une question : le code est mis au service de la police au bénéfice des citoyens (repérer les voitures volées, pister la délinquance…), mais peut fort bien ne faire qu’augmenter la surveillance de masse au détriment des mêmes citoyens, avec les conséquences pas du tout triviales qu’on connaît et dénonce régulièrement. Le fait que le code open source soit auditable est-il un garde-fou suffisant ?

Comment j’ai recréé un logiciel de 86 millions de dollars en 57 lignes de code

par Tait Brown

Publication originale : How I replicated an $86 million project in 57 lines of code
Traduction Framalang : xi, Lyn., goofy, framasky, Lumibd, Penguin

Quand un essai à base de technologie open source fait le boulot « suffisamment bien ».

La police est le principal acteur du maintien de l’ordre dans l’État du Victoria, en Australie. Dans cet État, plus de 16 000 véhicules ont été volés l’an passé, pour un coût d’environ 170 millions de dollars. Afin de lutter contre le vol de voitures, la police teste différentes solutions technologiques.

Pour aider à prévenir les ventes frauduleuses de véhicules volés, VicRoads propose déjà un service en ligne qui permet de vérifier le statut d’un véhicule en saisissant son numéro d’immatriculation. L’État a également investi dans un scanner de plaque minéralogique : une caméra fixe sur trépied qui analyse la circulation pour identifier automatiquement les véhicules volés.

Ne me demandez pas pourquoi, mais un après-midi, j’ai eu envie de réaliser un prototype de scanner de plaques minéralogiques embarqué dans une voiture, qui signalerait automatiquement tout véhicule volé ou non immatriculé. Je savais que tous les composants nécessaires existaient et je me suis demandé à quel point il serait compliqué de les relier entre eux.

Mais c’est après quelques recherches sur Google que j’ai découvert que la Police de l’État du Victoria avait récemment testé un appareil similaire dont le coût de déploiement était estimé à 86 millions de dollars australiens. Un commentateur futé a fait remarquer que 86 millions de dollars pour équiper 220 véhicules, cela représentait 390 909 AUSD par véhicule.
On devait pouvoir faire mieux que ça.

Les critères de réussite

Avant de commencer, j’ai défini à quelles exigences clés devait répondre la conception de ce produit.

Le traitement de l’image doit être effectué localement
Transmettre en continu le flux vidéo vers un site de traitement centralisé semblait l’approche la moins efficace pour répondre au problème. La facture pour la transmission des données serait énorme, de plus le temps de réponse du réseau ne ferait que ralentir un processus potentiellement assez long.
Bien qu’un algorithme d’apprentissage automatique centralisé ne puisse que gagner en précision au fil du temps, je voulais savoir si une mise en œuvre locale sur un périphérique serait « suffisamment bonne ».

Cela doit fonctionner avec des images de basse qualité
Je n’avais ni caméra compatible avec un Raspberry Pi, ni webcam USB, j’ai donc utilisé des séquences vidéo issues de dashcam [NdT : caméra installée dans un véhicule pour enregistrer ce que voit le conducteur], c’était immédiatement disponible et une source idéale de données d’échantillonnage. En prime, les vidéos dashcam ont, en général, la même qualité que les images des caméras embarquées sur les véhicules.

Cela doit reposer sur une technologie open source
En utilisant un logiciel propriétaire, vous vous ferez arnaquer chaque fois que vous demanderez un changement ou une amélioration, et l’arnaque se poursuivra pour chaque demande ultérieure. Utiliser une technologie open source évite ce genre de prise de tête.

Solution

Pour l’expliquer simplement, avec ma solution, le logiciel prend une image à partir d’une vidéo dashcam, puis l’envoie vers un système de reconnaissance des plaques minéralogiques open source installé localement dans l’appareil, il interroge ensuite le service de contrôle des plaques d’immatriculation et renvoie le résultat pour affichage.
Les données renvoyées à l’appareil installé dans le véhicule de police comprennent : la marque et le modèle du véhicule (pour vérifier si seules les plaques ont été volées), le statut de l’immatriculation et la notification d’un éventuel vol du véhicule.
Si cela semble plutôt simple, c’est parce que c’est vraiment le cas. Le traitement de l’image, par exemple, peut être opéré par la bibliothèque openalpr. Voici vraiment tout ce qu’il faut pour reconnaître les caractères sur les plaques minéralogiques :

 openalpr.IdentifyLicense(imagePath, function (error, output) {
 // handle result
 });
 (le code est sur Github)

Mise en garde mineure
L’accès public aux API de VicRoads n’étant pas disponible, les vérifications de plaques d’immatriculation se font par le biais du web scraping (NdT : une technique d’extraction automatisée du contenu de sites web) pour ce prototype. C’est une pratique généralement désapprouvée, mais il ne s’agit ici que d’un test de faisabilité et je ne surcharge pas les serveurs de quiconque.

Voici à quoi ressemble mon code, vraiment pas propre, utilisé pour tester la fiabilité de la récupération de données :

(le code est sur Github)

Résultats

Je dois dire que j’ai été agréablement surpris.

Je m’attendais à ce que la reconnaissance des plaques minéralogiques open source soit plutôt mauvaise. De plus, les algorithmes de reconnaissance d’images ne sont probablement pas optimisés pour les plaques d’immatriculation australiennes.

Le logiciel a été capable de reconnaître les plaques d’immatriculation dans un champ de vision large.

Toutefois, le logiciel a parfois des problèmes avec des lettres particulières.

Mais… il finit par les corriger :

Comme vous pouvez le voir dans les deux images ci-dessus, le traitement de l’image quelques images plus tard a bondi d’un indice de confiance de 87% à un petit peu plus de 91%.

Il s’agit de solutions très simples au niveau de la programmation, qui n’excluent pas l’entraînement du logiciel de reconnaissance des plaques d’immatriculation avec un ensemble de données locales.
Je suis certain que la précision pourrait être améliorée en augmentant le taux d’échantillonnage, puis en triant suivant le niveau de confiance le plus élevé. On pourrait aussi fixer un seuil qui n’accepterait qu’une confiance supérieure à 90% avant de valider le numéro d’enregistrement.
Il s’agit de choses très simples au niveau de la programmation, qui n’excluent pas l’entraînement du logiciel de reconnaissance des plaques d’immatriculation avec un jeu de données locales.

La question à 86 000 000 dollars

Pour être honnête, je n’ai absolument aucune idée de ce que le chiffre de 86 millions de dollars inclut – et je ne peux pas non plus parler de la précision d’un outil open source sans entraînement spécifique adapté au pays par rapport au système pilote BlueNet.
Je m’attendrais à ce qu’une partie de ce budget comprenne le remplacement de plusieurs bases de données et applications logicielles existantes pour répondre à des demandes de renseignements sur les plaques d’immatriculation à haute fréquence et à faible latence plusieurs fois par seconde par véhicule.
D’un autre côté, le coût de 391 000 dollars par véhicule semble assez élevé, surtout si le BlueNet n’est pas particulièrement précis et qu’il n’ existe pas de projets informatiques à grande échelle pour la mise hors service ou la mise à niveau des systèmes dépendants.

Applications futures

Bien qu’on puisse aisément être soucieux de la nature orwellienne d’un réseau qui fonctionne en continu de mouchards à plaques minéralogiques, cette technologie a de nombreuses applications positives. Imaginez un système passif qui analyse les autres automobilistes à la recherche d’une voiture de ravisseurs et qui avertit automatiquement et en temps réel les autorités et les membres de la famille de leur emplacement et de leur direction.

Les véhicules Tesla regorgent déjà de caméras et de capteurs capables de recevoir des mises à jour OTA (NdT : Over The Air, c’est-à-dire des mises à jour à distance) – imaginez qu’on puisse en faire une flotte virtuelle de bons Samaritains. Les conducteurs Uber et Lyft pourraient également être équipés de ces dispositifs pour augmenter considérablement leur zone de couverture.

En utilisant la technologie open source et les composants existants, il semble possible d’offrir une solution qui offre un taux de rendement beaucoup plus élevé – pour un investissement bien inférieur à 86 millions de dollars.

S’il est de notoriété publique que nos données personnelles sont enregistrées et utilisées par les G.A.F.A.M., il est en revanche moins connu que certaines de ces données sont utilisables par tout le monde. Et c’est bien là le point faible de toute campagne de prévention : on a beau dire que nos données sont utilisées, il est peu fréquent que nos paroles soient illustrées.

x0rz publie sur son blog un billet qui illustre parfaitement ce problème. En effet, il a écrit un petit script Python (moins de 400 lignes de code) qui récupère et synthétise les métadonnées Twitter, accessible par n’importe qui.

Ce billet ouvre deux perspectives :

• Concernant le harcèlement numérique : certes ces données sont publiques, mais il faut tout de même quelques capacités en programmation pour les exploiter, ce qui n’est pas à la portée de tout le monde. Imaginons qu’apparaissent de plus en plus de programmes grand public permettant d’accumuler et synthétiser ces données. Il deviendra alors plus facile pour un particulier d’identifier et de traquer une autre personne.
• Concernant les métadonnées en général : dans cet exemple, les données analysées restent très basiques (heure et localisation). Nous arrivons toutefois, par l’accumulation et le recoupement, à déduire des informations intéressantes de ces « méta-métadonnées », et à identifier nettement une personne. Imaginons que les métadonnées enregistrées soient plus précises et plus nombreuses, les informations obtenues seraient alors d’une importance et d’une précision inimaginables. Est-ce alors nécessaire de mentionner qu’à la fois les entreprises (ici Twitter) et les agences gouvernementales ont accès à ce genre de métadonnées ?

Article original écrit par x0rz, consultant en sécurité informatique, sur son blog.

Traduction Framalang : mo, mathis, goofy, valvin, Diane, Moriarty, Bromind et des anonymes

Vous serez surpris par tout ce que vos tweets peuvent révéler de vous et de vos habitudes

Une analyse de l’activité des comptes Twitter

J’utilise Twitter tous les jours. Pour moi qui suis consultant en cybersécurité, c’est de loin un des meilleurs outils pour rester informé des dernières actualités et pour partager des informations qu’on estime pertinentes pour d’autres. Avec la récente investiture de Donald Trump, les dingos de Twitter de la nouvelle administration et l’émergence de groupes de résistance sur Twitter, j’ai décidé de démontrer à quel point il est facile d’exposer des informations révélatrices à partir du compte de quelqu’un d’autre, sans même le pirater.

Métadonnées

Comme tous les réseaux sociaux, Twitter sait beaucoup de choses sur vous, grâce aux métadonnées. En effet, pour un message de 140 caractères, vous aurez un paquet de métadonnées, plus de 20 fois la taille du contenu initial que vous avez saisi ! Et vous savez quoi ? Presque toutes les métadonnées sont accessibles par l’API ouverte de Twitter.
Voici quelques exemples qui peuvent être exploités par n’importe qui (pas seulement les gouvernements) pour pister quelqu’un et en déduire son empreinte numérique :

• Fuseau horaire et langue choisie pour l’interface de twitter
• Langues détectées dans les tweets
• Sources utilisées (application pour mobile, navigateur web…)
• Géolocalisation
• Hashtags les plus utilisés, utilisateurs les plus retweetés, etc.
• Activité quotidienne/hebdomadaire

Tout le monde connaît les dangers des fuites de géolocalisation et à quel point elles nuisent à la confidentialité. Mais peu de gens se rendent compte que tweeter de façon régulière suffit à en dire beaucoup sur vos habitudes.
Prendre séparément un tweet unique peut révéler des métadonnées intéressantes. Prenez-en quelques milliers et vous allez commencer à voir se dessiner des lignes directrices. C’est là que ça devient amusant.

Méta-métadonnées

Une fois qu’on a collecté suffisamment de tweets d’un compte on peut par exemple identifier ceux qui relèvent d’une entreprise (émettant uniquement pendant les horaires de bureau) et même essayer de deviner combien d’utilisateurs interagissent avec ce compte.
Pour prouver ce que j’avance, j’ai développé un script en python qui récupère tous les derniers tweets de quelqu’un, extrait les métadonnées, et mesure l’activité en fonction de l’heure et du jour de la semaine.

Analyse du compte de @Snowden

Snowden a posté 1682 tweets depuis septembre 2015. Comme on peut le voir ci-dessous, il est facile de déterminer son rythme de sommeil (fuseau horaire de Moscou).

Analyse du compte de @realdonaldtrump

Est-ce que le compte de Donald Trump est géré par plusieurs personnes ? Cette fois en observant le nombre de sources détectées, je vous laisse deviner…

Recommandations générales

Je vous recommande fortement de lire les conseils de sécurité Twitter du Grugq. En plus de ce guide, je vous conseille d’être prudents avec les fuseaux horaires et les langues que vous utilisez, et d’être également conscients que vos tweets peuvent être analysés comme un tout : ne tweetez pas toujours à la même heure si vous ne voulez pas que les gens devinent votre fuseau horaire. Bien sûr, ces principes sont valables seulement si vous souhaitez rester anonyme, ne les appliquez pas à votre compte principal (ce serait une perte de temps) !

Code source

J’ai publié mon script sur GitHub. C’est open source donc n’hésitez pas à contribuer 😉

Nous arrivons bientôt au terme de notre traduction semaine après semaine de l’ouvrage Des routes et des ponts de Nadia Eghbal (version originale en PDF). Pour remonter vers les épisodes précédents il suffit de cliquer sur ce lien.

Aujourd’hui nous vous proposons un chapitre qui recense les moyens dont les institutions et entreprises pourraient contribuer au développement et à la pérennité des projets open source qui constituent la colonne vertébrale de l’infrastructure numérique.

Traduction Framalang : Penguin, lyn, goofy, Opsylac, xXx

Une esquisse du tableau

Il est trop tôt pour dire à quoi devrait ressembler le soutien institutionnel à long terme d’un point de vue prospectif, mais il y a plusieurs domaines de travail critiques qui peuvent nous aider à le déterminer. Les propositions suivantes sont rattachées à trois domaines :

• Traiter les infrastructures numériques comme un bien commun essentiel et les élever au rang d’acteur intersectoriel clé ;
• Travailler avec des projets pour améliorer les standards, la sécurité et les flux de production ;
• Augmenter la taille du groupe de contributeurs de manière à ce que davantage de personnes, et davantage de personnes de types différents, puissent élaborer et soutenir ensemble les logiciels publics.

Conscientiser et éduquer les acteurs clés

Comme nous l’avons relevé dans ce rapport, beaucoup d’acteurs clés — dont les startups, les gouvernements, et les sociétés de capital risque — pensent à tort que les logiciels publics « fonctionnent, tout simplement » et ne requiert pas de maintenance supplémentaire. Pour entretenir correctement l’écosystème de nos infrastructures numériques, ces populations devraient être les premières à être informées du problème. Les infrastructures numériques ont besoin de porte-paroles qui soient affranchis de toute contrainte politique ou commerciale et qui puissent comprendre et communiquer les besoins de l’écosystème.

Traiter les infrastructures numériques comme des biens publics essentiels pourrait également motiver l’investissement direct dans la construction de meilleurs systèmes à partir de zéro. Par exemple, aux États-Unis, les autoroutes inter-états et le réseau de bibliothèques publiques furent dès l’origine conçus comme des ressources publiques. Les unes et les autres ont eu leur champion (respectivement le Président Dwight Eisenhower et le philanthrope Andrew Carnegie) qui ont clairement argumenté en faveur du bénéfice social et financier qui résulterait de tels projets.

Un réseau national d’autoroutes ne sert pas uniquement à nous relier en tant qu’individus, en facilitant les déplacements d’un endroit à un autre, mais il apporte aussi la prospérité financière dans tous les coins du pays, grâce à l’usage commercial des voies rapides pour acheminer les marchandises. Dans les bibliothèques Andrew Carnegie, publiques et gratuites, les livres étaient accessibles et non stockés en magasin, pour permettre aux gens de les feuilleter et d’y trouver eux-mêmes l’information sans avoir recours à un⋅e bibliothécaire. Cette pratique a aidé à démocratiser l’information et à donner aux gens les moyens de s’éduquer eux-mêmes.

Une meilleure éducation et une meilleure prise de conscience pourraient s’étendre jusqu’aux gouvernements, dont certains ont rendu, par la loi, les infrastructures numériques difficiles à soutenir et qui ne sont peut-être pas familiers des normes culturelles et de l’histoire de l’open source. Aux USA, l’IRS [NdT : Internal Revenue Service – organisme qui collecte l’impôt] a une définition très restrictive des activités caritatives, et comme l’open source est mal comprise, son impact positif sur la société demeure ignoré. Cela complique l’institutionnalisation de plus gros projets à travers une fondation ou une association professionnelle.

Mesurer l’utilisation et l’impact de l’infrastructure numérique

L’impact de l’infrastructure numérique est encore très difficile à mesurer. Les indicateurs habituels sont soit très imprécis, soit simplement indisponibles. Ce n’est pas un problème facile à résoudre. Mais sans données relatives aux outils utilisés et à notre dépendance vis-à-vis d’eux, il est difficile de se faire une idée nette de ce qui manque de financement.

Avec de meilleurs indicateurs, nous pourrions décrire l’impact économique de l’infrastructure numérique, identifier les projets essentiels qui manquent de financement, et comprendre les dépendances entre les projets et entre les personnes. Pour le moment, il est impossible de dire qui utilise un projet open source à moins que l’utilisateur, individu ou entreprise, ne le révèle. Pour déterminer quel projet a besoin de plus de soutien, nous ne disposons que d’informations anecdotiques.

De meilleures statistiques pourraient également nous aider à identifier les « contributeurs clé de voûte ». En biologie environnementale, une « espèce clé » est une espèce animale qui a un impact disproportionné sur son environnement au regard de ses effectifs. Dans la même idée, un « contributeur clé » pourrait être un développeur qui contribue à plusieurs projets essentiels, qui est le seul responsable d’un projet crucial, ou qui est généralement perçu comme influent et digne de confiance. Les « contributeurs clés » sont des défenseurs essentiels, les valoriser en leur fournissant les ressources dont ils ont besoin pourrait améliorer le système dans son ensemble. Comprendre les relations entre les communautés open source et les « contributeurs clés » pourrait aider à identifier rapidement les secteurs qui auront besoin de soutien supplémentaire.

On dispose également de peu de données sur les contributeurs eux-mêmes : qui contribue à l’open source, quelles conditions leur permettent de le faire, et quelles sont les contributions effectuées. Les femmes, les non-anglophones, et les nouveaux contributeurs à l’open source sont des exemples de population qui devraient être suivies dans le temps, en particulier pour mesurer l’impact des programmes de soutien.

Les seules statistiques disponibles sur les dépôts GitHub sont le nombre de personnes ayant étoilé (action semblable à liker), vu (c’est-à-dire qu’elles reçoivent des nouvelles du projet) ou « forké » un projet. Ces chiffres permettent de fournir des indicateurs concernant la popularité, mais ils peuvent être trompeurs. Beaucoup de personnes peuvent étoiler un projet, parce qu’il a une conception intéressante par exemple, sans toutefois l’intégrer à leur propre code.

Certains gestionnaires de paquets tels npm (qui est celui de Node.js) suivent les téléchargements. Le « popularity contest » de Debian piste les téléchargements du système d’exploitation libre Debian. Néanmoins, chaque gestionnaire de paquets est limité à un écosystème particulier, et aucun de ces gestionnaires ne peut donner une image du système dans son ensemble. Plusieurs projets ne sont pas inclus dans un gestionnaire de paquets et ne sont pas suivis. Libraries.io, un site web créé par Andrew Nesbitt, est une tentative pour agréger des données des projets open source en fonction de leur usage, il piste environ 1,3 millions de bibliothèques open source sur 32 gestionnaires de paquets.

Travailler avec les projets pour moderniser l’organisation de travail

Beaucoup de projets sont en difficulté et pas seulement à cause d’un manque de financement, mais aussi parce qu’il est difficile d’y contribuer, ou encore parce qu’il existe un goulot d’étranglement au niveau des mainteneurs qui traitent les demandes de modification (pull requests) de la communauté. C’est vrai, en particulier, pour les plus anciens projets qui ont été bâtis avec des outils de développement, des langages et des processus qui ne sont plus populaires (ceux qui par exemple utilisent un système de contrôle de version autre que Git, dont la popularité croît chez les développeurs).

On peut faire beaucoup de choses pour faciliter la contribution à un projet, depuis la migration vers un flux de travail (workflow) plus moderne, le nettoyage du code, la fermeture des pull request délaissées, jusqu’à la mise en place d’une politique claire pour les contributions. Certains projets expérimentent pour rendre les contributions plus simples. Le développeur Felix Geisendörfer, par exemple, a suggéré que chaque personne qui soumet une modification du code devrait avoir une permission de commit afin de réduire l’engorgement au niveau de l’unique mainteneur vérifiant et approuvant ces changements. Felix a estimé que « cette approche est un fantastique moyen d’éviter que le projet ne se ratatine en transformant le projet d’un seul homme en celui d’une communauté. »

Le règlement de contribution de Node.js, qui peut être adopté par les autres projets Node, met l’accent sur l’augmentation du nombre de contributeurs et sur leur autonomisation dans la prise de décision, plutôt que de désigner les mainteneurs comme seule autorité approbatrice. Leurs règles de contribution expliquent comment soumettre et valider des pull requests, comment consigner des bugs, etc. Les mainteneurs Node.js ont constaté qu’adopter de meilleures règles les avait aidés à gérer leur charge de travail et à faire évoluer leur communauté vers un projet plus sain et actif.

Dans un premier temps, il y a des recherches à faire pour déterminer quels projets doivent avancer. Autrement dit, à quoi ressemble un « projet à succès », aussi bien en termes de financement et de modèles de gouvernance, que dans l’équilibre à trouver entre mainteneurs, contributeurs et usagers ! La réponse peut varier en fonction des différents types de projets et de leur ampleur.

Encourager les standards communs dans les projets open source

Bien que GitHub soit en train de devenir une plateforme standard pour la collaboration sur le code, de nombreux aspects des projets open source ne sont pas encore standardisés, notamment l’ampleur et la richesse de la documentation, des licences et des guides de contribution, ainsi que le style de code et le formatage.
Encourager l’adoption de standards de projets pourrait faciliter, pour les mainteneurs, la gestion des contributions, tout en réduisant pour les contributeurs les obstacles à la participation.

Parmi les exemples de standardisation croissante, on trouve le code de conduite, qui est un règlement détaillant les attentes en termes d’attitude et de communication.
Ces dernières années, des codes de conduite ont été adoptés par un nombre croissant de communautés de projets, notamment Node.js, Django et Ruby. Bien que le processus d’adoption ait pu donner lieu à d’intenses débats au sein de certaines communautés, leur prolifération révèle un intérêt croissant pour la responsabilisation du comportement des communautés.

Augmenter le nombre de contributeurs et contributrices open source

Comme nous l’avons évoqué dans un chapitre précédent de ce rapport, l’industrie du logiciel est florissante, avec un nombre croissant de nouveaux développeurs mais aussi d’autres talents variés : il y a du travail à faire pour encourager ces nouveaux arrivants à contribuer à l’open source. Augmenter le nombre de contributeurs permet aux projets open source d’être plus durables, car davantage de personnes participent à leur développement. Permettre à davantage de personnes de contribuer à l’open source accroît également l’empathie et la communication entre les « utilisateurs » de l’open source et les projets dont ils dépendent.

« Your First PR » (« votre première PR », PR pour Pull Request, NdT) est un exemple d’initiative, développée par la programmeuse Charlotte Spencer, qui aide les nouveaux venus à effectuer leur première contribution à l’open source. « First Timers Only » (Réservé aux débutants) et « Make a Pull Request » (Faites une pull request) sont deux autres exemples de ressources populaires qui introduisent les nouveaux venus à l’open source. Certains projets open source utilisent également des étiquettes telles que « first bug » ou « contributor friendly » pour signaler les problèmes susceptibles d’être résolus par des contributeurs moins expérimentés. Il serait également bénéfique d’encourager les contributions à l’open source autres que le code, comme la rédaction de documentation technique, la gestion des tâches et des flux de travail, ou la création d’un site internet pour le projet.

En plus de l’augmentation de la proportion de techniciens talentueux contribuant à l’open source existe la possibilité de puiser dans un groupe de contributeurs plus large. Faire en sorte que les non-anglophones se sentent bienvenus dans les communautés open source, par exemple, pourrait rendre la technologie plus accessible à travers le monde. Et comme beaucoup de recruteurs utilisent les travaux open source comme un portfolio au moment d’embaucher un développeur, une communauté open source plus diverse encouragerait l’apparition d’un personnel technique globalement plus inclusif.

Améliorer les relations entre projets et acteurs extérieurs

Les entreprises sont une pièce incontournable de l’écosystème open source, et leur rôle ne fait que gagner en importance à mesure que davantage d’entre elles adoptent les logiciels open source. Faciliter la collaboration entre entreprises et projets, ainsi qu’aider les entreprises à comprendre les besoins des communautés open source, pourrait débloquer le soutien des entreprises susceptibles de devenir mécènes ou promoteurs de l’open source.

Selon l’étude annuelle des entreprises open source réalisée par Black Duck, seulement 27 % des entreprises ont un règlement formel concernant les contributions de leurs employés à l’open source. Clarifier la possibilité ou non pour les employés de contribuer à l’open source sur leur temps de travail, et les encourager à le faire, pourrait grandement améliorer le soutien des entreprises aux projets open source.

En 2014, un groupement d’entreprises a fondé le TODO Group, pour partager les bonnes pratiques autour de la participation corporative à l’open source. Parmi les membres de ce groupe, on trouve Box, Facebook, Dropbox, Twitter et Stripe. En mars 2016, le TODO Group a annoncé qu’il serait hébergé par la Fondation Linux en tant que projet collaboratif.

Les entreprises peuvent également fournir un soutien financier aux projets, mais il est parfois difficile pour elles de trouver comment formaliser leur mécénat. Créer des budgets dédiés au mécénat en direction des équipes d’ingénieurs ou des employés, ou encore créer des documents permettant aux projets de « facturer » plus facilement leurs services aux entreprises, sont autant d’initiatives qui pourraient augmenter les contributions financières à l’open source.

Poul-Henning Kamp, par exemple, travaille sur un projet open source nommé Varnish, utilisé par un dixième des sites les plus visités d’internet, notamment Facebook, Twitter, Tumblr, The New York Times et The Guardian. Pour financer ce travail, il a créé la Varnish Moral License pour faciliter la sponsorisation du projet par les entreprises.

Même si en pratique la relation est un mécénat, Poul Henning utilise une terminologie familière aux entreprises, avec des termes tels que « facturation » et « licences », pour réduire les obstacles à la participation.

Augmenter le soutien aux compétences diverses et aux fonctions hors-codage

Dans un passé pas si lointain, les startups de logiciels étaient fortement centrées sur les compétences techniques. Les autres rôles, comme le marketing et le design, étaient considérés comme secondaires par rapport au code. Aujourd’hui, avec la création et la consommation rapide de logiciels, cette conception ne tient plus. Les startups sont en concurrence pour capter l’attention de leurs clients. L’identité de la marque est devenue l’un des principaux facteurs de différenciation.

Ces cinq dernières années ont été celles de l’essor du développeur full stack (polyvalent) : des développeurs plus généralistes que spécialisés, capables de travailler sur plusieurs domaines d’un logiciel complexe, et qui sont susceptibles d’avoir des compétences dans la conception et la production. Les équipes de développement sont plus soudées, elles utilisent les méthodes agiles avec des approches de conception d’architecture logicielle (où le livrable est élaboré en faisant des navettes entre les équipes de techniciens, designers et commerciaux), plutôt qu’une approche en cascade (où chaque équipe apporte sa pièce à l’édifice avant de la transmettre au groupe de travail suivant).

Les projets open source ont connu peu d’évolutions de ce genre, malgré notre dépendance croissante à leurs logiciels. On comprend aisément que le code soit au cœur d’un projet open source, il est en quelque sorte le « produit final » ou le livrable. Les fonctions relatives à la gestion de la communauté, à la documentation, ou à la promotion du projet, qui sont la marque d’une organisation saine et durable, sont moins valorisées. Il en découle que les projets sont déséquilibrés. Beaucoup de choses pourraient être entreprises pour financer et soutenir les contributions autres que le code, des dons en nature pour payer les serveurs par exemple, ou des avantages comme une assurance maladie. Disposer de soutiens de ce type permettrait de réduire notablement la charge des développeurs.

Voici le plus long des chapitres de Des routes et des ponts de Nadia Ehgbal que nous traduisons pour vous semaine après semaine (si vous avez raté les épisodes précédents). Il s’agit cette fois-ci des institutions (ici nord-américaines) qui par diverses formes de mécénat, contribuent au développement et au maintien des projets d’infrastructure numérique open source parce qu’elles y trouvent leur intérêt. Pas sûr qu’en Europe et en France ces passerelles et ces coopérations bien comprises entre entreprises et open source soient aussi habituelles…

Traduction Framalang :  Opsylac, Luc, jums, xi, serici, lyn, mika, AFS, Goofy

Les efforts institutionnels pour financer les infrastructures numériques

Il existe des institutions qui s’efforcent d’organiser collectivement les projets open source et aider à leur financement. Il peut s’agir de fondations indépendantes liées aux logiciels, ou d’entreprises de logiciels elles-mêmes qui apportent leur soutien.

Soutien administratif et mécénat financier

Plusieurs fondations fournissent un soutien organisationnel, comme le mécénat financier, aux projets open source : en d’autres termes, la prise en charge des tâches autres que le code, dont beaucoup de développeurs se passent volontiers. L’Apache Software Foundation, constituée en 1999, a été créée en partie pour soutenir le développement du serveur Apache HTTP, qui dessert environ 55 % de la totalité des sites internet dans le monde.

Depuis lors, la fondation Apache est devenue un foyer d’ancrage pour plus de 350 projets open source. Elle se structure comme une communauté décentralisée de développeurs, sans aucun employé à plein temps et avec presque 3000 bénévoles. Elle propose de multiples services aux projets qu’elle héberge, consistant principalement en un soutien organisationnel, juridique et de développement. En 2011, Apache avait un budget annuel de plus de 500 000 $, issu essentiellement de subventions et de donations.

Le Software Freedom Conservancy, fondée en 2006, fournit également des services administratifs non-lucratifs à plus de 30 projets libres et open source. Parmi les projets que cette fondation soutient, on retrouve notamment Git, le système de contrôle de versions dont nous avons parlé plus haut et sur lequel GitHub a bâti sa plateforme, et Twisted, une librairie Python déjà citée précédemment.

On trouve encore d’autres fondations fournissant un soutien organisationnel, par exemple The Eclipse Foundation et Software in the Public Interest. La Fondation Linux et la Fondation Mozilla soutiennent également des projets open source externes de diverses façons (dont nous parlerons plus loin dans ce chapitre), bien que ce ne soit pas le but principal de leur mission.

Il est important de noter que ces fondations fournissent une aide juridique et administrative, mais rarement financière. Ainsi, être sponsorisé par Apache ou par le Software Freedom Conservancy ne suffit pas en soi à financer un projet ; les fondations ne font que faciliter le traitement des dons et la gestion du projet.

Un autre point important à noter, c’est que ces initiatives soutiennent le logiciel libre et open source d’un point de vue philosophique, mais ne se concentrent pas spécifiquement sur ses infrastructures. Par exemple, OpenTripPlanner, projet soutenu par le Software Freedom Conservancy, est un logiciel pour planifier les voyages : même son code est open source, il s’agit d’une application destinée aux consommateurs, pas d’une infrastructure.

Créer une fondation pour aider un projet

Certains projets sont suffisamment importants pour être gérés à travers leurs propres fondations. Python, Node.js, Django et jQuery sont tous adossés à des fondations.

Il y a deux conditions fondamentales à remplir pour qu’une fondation fonctionne : accéder au statut d’exemption fiscale et trouver des financements.

Réussir à accéder au statut 501(c), la loi américaine qui définit les organismes sans but lucratif, peut s’avérer difficile pour ces projets, à cause du manque de sensibilisation autour de la technologie open source et de la tendance à voir l’open source comme une activité non-caritative. En 2013, une controverse a révélé que l’IRS (Internal Revenue Service, service des impôts américain) avait dressé une liste de groupes postulant au statut d’exemption fiscale qui nécessiteraient davantage de surveillance : l’open source en faisait partie. Malheureusement, ces contraintes ne facilitent pas l’institutionnalisation de ces projets.

Par exemple, Russell Keith-Magee, qui était jusqu’à une époque récente président de la Django Software Foundation, a expliqué que la fondation ne pouvait pas directement financer le développement logiciel de Django, sans prendre le risque de perdre son statut 501(c). La fondation soutient plutôt le développement via des activités communautaires.

En juin 2014, la Fondation Yorba, qui a créé des logiciels de productivité qui tournent sous Linux, s’est vu refuser le statut 501(c) après avoir attendu la décision pendant presque quatre ans et demi. Jim Nelson, son directeur exécutif, a été particulièrement inquiété par le raisonnement de l’IRS : parce que leur logiciel pouvait potentiellement être utilisé par des entités commerciales, le travail de Yorba ne pouvait pas être considéré comme caritatif. Une lettre de l’IRS explique :

« Se contenter de publier sous une licence open source tous usages ne signifie pas que les pauvres et les moins privilégiés utiliseront effectivement les outils. […] On ne peut pas savoir qui utilise les outils, et encore moins quel genre de contenus sont créés avec ces outils. »

Nelson a pointé les failles de ce raisonnement dans un billet de blog, comparant la situation à celle d’autres biens publics :

« Il y a une organisation caritative ici à San Francisco qui plante des arbres pour le bénéfice de tous. Si l’un de leurs arbres… rafraîchit les clients d’un café pendant qu’ils profitent de leur expresso, cela signifie-t-il que l’organisation qui plante des arbres n’est plus caritative ? »

Les projets qui accèdent au statut 501(c) ont tendance à insister sur l’importance de la communauté, comme la Python Software Foundation, dont l’objet est de « promouvoir, protéger et faire progresser le langage de programmation Python, ainsi que de soutenir et faciliter la croissance d’une communauté diversifiée et internationale de programmeurs Python ».

En parallèle, certains projets candidatent pour devenir une association de commerce au sens du statut 501(c)(6). La Fondation jQuery en est un exemple, se décrivant comme « une association de commerce à but non-lucratif pour développeurs web, financée par ses membres ». La Fondation Linux est également une association de commerce.

Le deuxième aspect de la formalisation de la gouvernance d’un projet à travers une fondation est la recherche de la source de financement adéquate. Certaines fondations sont financées par des donations individuelles, mais ont proportionnellement de petits budgets.

La Django Software Foundation, par exemple, gère Django, le plus populaire des frameworks web écrits en Python, utilisé par des entreprises comme Instagram et Pinterest. La Fondation est dirigée par des bénévoles, et reçoit moins de 60 000 $ de donations par an. L’année dernière, la Django Software Foundation a reçu une subvention ponctuelle de la part de la Fondation Mozilla.

Parmi les autres sources habituelles de financement on trouve les entreprises mécènes. En effet, les entreprises privées sont bien placées pour financer ces projets logiciels, puisqu’elles les utilisent elles-mêmes. La Fondation Linux est l’un de ces cas particuliers qui rencontrent le succès, et ce grâce la valeur fondamentale du noyau Linux pour les activités de quasiment toutes les entreprises. La Fondation Linux dispose de 30 millions de dollars d’un capital géré sur une base annuelle, alimenté par des entreprises privées comme IBM, Intel, Oracle et Samsung – et ce chiffre continue d’augmenter.

Créer une fondation pour soutenir un projet est une bonne idée pour les projets d’infrastructure très conséquents. Mais cette solution est moins appropriée pour de plus petits projets, en raison de la quantité de travail, des ressources, et du soutien constant des entreprises, nécessaires pour créer une organisation durable.

Node.js est un exemple récent d’utilisation réussie d’une fondation pour soutenir un gros projet. Node.js est un framework JavaScript, développé en 2009 par Ryan Dahl et différents autres développeurs employés par Joyent, une entreprise privée du secteur logiciel. Ce framework est devenu extrêmement populaire, mais a commencé à souffrir de contraintes de gouvernance liées à l’encadrement par Joyent, que certaines personnes estimaient incapable de représenter pleinement la communauté enthousiaste et en pleine croissance de Node.js.

En 2014, un groupe de contributeurs de Node.js menaça de forker le projet. Joyent essaya de gérer ces problèmes de gouvernance en créant un conseil d’administration pour le projet, mais la scission eut finalement lieu, le nouveau fork prenant le nom d’io.js. En février 2015 fut annoncée l’intention de créer une organisation 501(c) (6) en vue d’extraire Node.js de la mainmise de Joyent. Les communautés Node.js et io.js votèrent pour travailler ensemble sous l’égide de cette nouvelle entité, appelée la Fondation Node.js. La Fondation Node.js, structurée suivant les conseils de la Fondation Linux, dispose d’un certain nombre d’entreprises mécènes qui contribuent financièrement à son budget, notamment IBM, Microsoft et payPal. Ces sponsors pensent retirer une certaine influence de leur soutien au développement d’un projet logiciel populaire qui fait avancer le web, et ils ont des ressources à mettre à disposition.

Un autre exemple prometteur est Ruby Together, une organisation initiée par plusieurs développeurs Ruby pour soutenir des projets d’infrastructure Ruby. Ruby Together est structuré en tant qu’association commerciale, dans laquelle chaque donateur, entreprise ou individu, investit de l’argent pour financer le travail à temps plein de développeurs chargés d’améliorer le cœur de l’infrastructure Ruby. Les donateurs élisent un comité de direction bénévole, qui aide à décider chaque mois sur quels projets les membres de Ruby Together devraient travailler.

Ruby Together fut conçue par deux développeurs et finance leur travail de  : André Arko et David Radcliffe. Aujourd’hui, en avril 2016, est également rémunéré le travail de quatre autres mainteneurs d’infrastructure. Le budget mensuel en mars 2016 était d’un peu plus de 18 000 dollars par mois, couvert entièrement par des dons. La création de Ruby Together fut annoncée en mars 2015 et reste un projet récent, mais pourrait bien servir de base à un modèle davantage orienté vers la communauté pour financer la création d’autres projets d’infrastructure.

Programmes d’entreprises

Les éditeurs de logiciels soutiennent les projets d’infrastructure de différentes manières.

En tant que bénéficiaires des projets d’infrastructures, ils contribuent en faisant remonter des dysfonctionnements et des bugs, en proposant ou soumettant de nouvelles fonctionnalités ou par d’autres moyens. Certaines entreprises encouragent leurs employés à contribuer à des projets d’une importance critique sur leur temps de travail. De nombreux employés contribuent ainsi de manière significative à des projets open source extérieurs à l’entreprise. Pour certains employés, travailler sur de l’open source fait clairement partie de leur travail. L’allocation de temps de travail de leurs salariés est une des plus importantes façons de contribuer à l’open source pour les entreprises.

Les grandes entreprises comme Google ou Facebook adhèrent avec enthousiasme à l’open source, de façon à inspirer confiance et renforcer leur influence ; elles sont de fait les seuls acteurs institutionnels assez importants qui peuvent assumer son coût sans avoir besoin d’un retour financier sur investissement. Les projets open source aident à renforcer l’influence d’une entreprise, que ce soit en publiant son propre projet open source ou en embauchant des développeurs de premier plan pour qu’ils travaillent à plein temps sur un projet open source.

Ces pratiques ne sont pas limitées aux entreprises purement logicielles. Walmart, par exemple, qui est un soutien majeur de l’open source, a investi plus de deux millions de dollars dans un projet open source nommé hapi. Eran Hammer, développeur senior à Walmart Labs, s’est empressé de préciser que « l’open source, ce n’est pas du caritatif » et que les ressources d’ingénierie gratuites sont proportionnelles à la taille des entreprises qui utilisent hapi. Dion Almaer, l’ancien vice-président en ingénierie de Walmart Labs, a remarqué que leur engagement envers l’open source les aidait à recruter, à construire une solide culture d’entreprise, et à gagner « une série d’effets de levier ».

En termes de soutien direct au maintien du projet, il arrive que des entreprises embauchent une personne pour travailler à plein temps à la maintenance d’un projet open source. Les entreprises donnent aussi occasionnellement à des campagnes de financement participatif pour un projet particulier. Par exemple, récemment, une campagne sur Kickstarter pour financer un travail essentiel sur Django a reçu 32 650 £ (environ 40 000 €) ; Tom Christie, l’organisateur de la campagne, a déclaré que 80 % du total venait d’entreprises. Cependant, ces efforts sont toujours consacrés à des projets  spécifiques et les infrastructures numériques ne sont pas encore vues communément comme une question de responsabilité sociale par les entreprises de logiciel à but lucratif. Cela laisse encore beaucoup de marge aux actions de défense et promotion.

L’un des programmes d’entreprise les plus connus est le Summer of Code de Google (été de programmation, souvent nommé GSoC), déjà mentionné dans ce livre, qui offre de l’argent à des étudiant⋅e⋅s pour travailler sur des projets open source pendant un été. Les étudiant⋅e⋅s sont associé⋅e⋅s à des mentors qui vont les aider à se familiariser avec le projet. Le Summer of Code est maintenu par le bureau des programmes open source de Google, et il a financé des milliers d’étudiant⋅e⋅s.

Le but du Summer of Code est de donner à des étudiants la possibilité d’écrire du code pour des projets open source, non de financer les projets eux-mêmes.

L’an dernier, Stripe, une entreprise de traitement des paiements, a annoncé une « retraite  open source », offrant un salaire mensuel d’un maximum de 7500 dollars pour une session de trois mois dans les locaux de Stripe. À l’origine, l’entreprise voulait uniquement offrir deux bourses, mais après avoir reçu 120 candidatures, le programme a été ouvert à quatre bénéficiaires.

Ces derniers ont été enchantés par cette expérience. L’un d’entre eux, Andrey Petrov, continue de maintenir la bibliothèque Python urllib3 dont nous avons déjà parlé, et qui est largement utilisée dans l’écosystème Python.

À propos de cette expérience, Andrey a écrit :

« La publication et la contribution au code open source vont continuer que je sois payé pour ou non, mais le processus sera lent et non ciblé. Ce qui n’est pas un problème, car c’est ainsi que l’open source a toujours fonctionné. Mais on n’est pas obligé d’en rester là. […] 

Si vous êtes une entreprise liée à la technologie, allouez s’il vous plaît un budget pour du financement et des bourses dans le domaine de l’open source. Distribuez-le sur Gittip [Note : Gittip est maintenant dénommé Gratipay. Le produit a été quelque peu modifié depuis la publication originelle du billet d’Andrew] si vous voulez, ou faites ce qu’a fait Stripe et financez des sprints ambitieux pour atteindre des objectifs de haute valeur. 

Considérez ceci comme une demande solennelle  de parrainage : s’il vous plaît, aidez au financement du développement d’urllib3. »

La retraite open source de Stripe peut servir de modèle aux programmes de soutien. Stripe a décidé de reconduire le programme pour une deuxième année consécutive en 2015. Malgré la popularité de leur programme et la chaude réception qu’il a reçue chez les développeurs et développeuses, cette pratique n’est toujours pas répandue dans les autres entreprises.

Les entreprises montrent un intérêt croissant pour l’open source, et personne ne peut prédire au juste ce que cela donnera sur le long terme. Les entreprises pourraient régler le problème du manque de support à long terme en consacrant des ressources humaines et un budget aux projets open source. Des programmes de bourse formalisés pourraient permettre de mettre en contact des entreprises avec des développeurs open source ayant besoin d’un soutien à plein temps. Alors que les équipes de contributeurs à un projet étaient souvent composées d’une diversité de développeurs venant de partout, peut-être seront-elles bientôt composées par un groupe d’employés d’une même entreprise. Les infrastructures numériques deviendront peut-être une série de « jardins clos », chacun d’entre eux étant techniquement ouvert et bénéficiant d’un soutien solide, mais en réalité, grâce à ses ressources illimitées, une seule entreprise et de ses employés en assureront le soutien.

Mais si on pousse la logique jusqu’au bout, ce n’est pas de très bon augure pour l’innovation. Jeff Lindsay, un architecte logiciel qui a contribué à mettre en place l’équipe de Twilio, une entreprise  performante de solutions de communication dans le cloud, livrait  l’an dernier ses réflexions dans une émission :

« À Twilio, on est incité à améliorer le fonctionnement de Twilio, à Amazon on est incité à améliorer le fonctionnement d’Amazon. Mais qui est incité à mieux les faire fonctionner ensemble et à offrir plus de possibilités aux usagers en combinant les deux ? Il n’y a personne qui soit vraiment incité à faire ça. »

Timothy Fuzz, un ingénieur système, ajoute :

« Pour Bruce Schneier, cette situation tient du servage. Nous vivons dans un monde où Google est une cité-état, où Apple est une cité-état et… si je me contente de continuer à utiliser les produits Google, si je reste confiné dans l’environnement Google, tout me paraît bénéfique. Mais il est quasi impossible de vivre dans un monde où je change d’environnement : c’est très pénible, vous tombez sur des bugs, et aucune de ces entreprises ne cherche vraiment à vous aider. Nous sommes dans ce monde bizarre, mais si vous regardez du côté des cités-états, l’un des problèmes majeurs c’est le commerce inter-étatique : si on doit payer des droits de douane parce qu’on cherche à exporter quelque chose d’Austin pour le vendre à Dallas, ce n’est pas un bon modèle économique. On pâtit de l’absence d’innovation et de partage des idées. On en est là, aujourd’hui. »

Bien que l’argument du « servage » se réfère généralement aux produits d’une entreprise, comme l’addiction à l’iPhone ou à Android, il pourrait être tout aussi pertinent pour les projets open source parrainés. Les améliorations prioritaires seront toujours celles qui bénéficient directement à l’entreprise qui paie le développeur. Cette remarque ne relève pas de la malveillance ou de la conspiration : simplement, être payé par une entreprise pour travailler à un projet qui ne fait pas directement partie de ses affaires est une contrainte à prendre en compte.

Mais personne, pas plus Google que la Fondation Linux ou qu’un groupe de développeurs indépendants, ne peut contrôler l’origine d’un bon projet open source. Les nouveaux projets de valeur peuvent germer n’importe où, et quand ils rendent un service de qualité aux autres développeurs, ils sont largement adoptés. C’est une bonne chose et cela alimente l’innovation.

Aide spécifique de fondation

Deux fondations ont récemment fait part de leur décision de financer plus spécifiquement l’infrastructure numérique : la Fondation Linux et la Fondation Mozilla.

Après la découverte de la faille Heartbleed, la Fondation Linux a annoncé qu’elle mettait en place l’Initiative pour les infrastructures essentielles (Core Infrastructure Initiative, CII) pour éviter que ce genre de problème ne se reproduise. Jim Zemlin, le directeur-général de la Fondation Linux, a réuni près de 4 millions de dollars en promesses de dons provenant de treize entreprises privées, dont Amazon Web Services, IBM et Microsoft, pour financer des projets liés à la sécurité des infrastructures pour les trois ans à venir. La Fondation Linux s’occupe également d’obtenir des financements gouvernementaux, y compris de la Maison-Blanche.

La CII est officiellement un projet de la fondation Linux. Depuis sa création en avril 2014, la CII a sponsorisé du travail de développement d’un certain nombre de projets, dont OpenSSL, NTP, GnuPG (un système de chiffrement des communications) et OpenSSH (un ensemble de protocoles relatifs à la sécurité). La CII se concentre en priorité sur une partie de l’infrastructure numérique : les projets relatifs à la sécurité.

Au mois d’octobre 2015, Mitchell Baker, la présidente de la Fondation Mozilla, a annoncé la création du Programme de soutien à l’open source de Mozilla (Mozilla Open Source Support Program, MOSS) et a promis de consacrer un million de dollars au financement de logiciels libres et open source. Selon Baker, ce programme aura deux volets : un volet « rétribution » pour les projets qu’utilise Mozilla et un volet « contribution » pour les projets libres et open source en général. Grâce aux suggestions de la communauté, Mozilla a sélectionné neuf projets pour la première série de bourses. Ils se disent également prêts à financer des audits de sécurité pour les projets open source importants.

Enfin, certaines fondations contribuent ponctuellement à des projets de développement logiciel. Par exemple, la Python Software Foundation propose aux individus et aux associations des bourses modestes destinées pour la plupart aux actions pédagogiques et de sensibilisation.

Autres acteurs institutionnels

Il existe plusieurs autres acteurs qui apportent diverses formes de soutien aux infrastructures numériques : Github, le capital-risque et le monde universitaire. Si Facebook est un « utilitaire social » et Google un « utilitaire de recherche », tous deux régulant de facto les corps dans leur domaine respectif – alors Github a une chance de devenir « l’utilitaire open source ». Son modèle économique l’empêche de devenir un mastodonte financier (contrairement à Facebook ou Google dont le modèle est basé sur la publicité, alors que Github se monétise par l’hébergement de code pour les clients professionnels, et par l’hébergement individuel de code privé), mais Github est toujours un endroit où aujourd’hui encore l’open source est créée et maintenue.

Github s’est doté de grandes aspirations avec une levée de fonds de capital-risque de 350 millions de dollars, même si l’entreprise était déjà rentable. Si Github assume pleinement son rôle d’administrateur du code open source, l’organisation peut avoir une énorme influence sur le soutien apporté à ces projets. Par exemple, elle peut créer de meilleurs outils de gestion de projets open source, défendre certaines catégories de licences, ou aider les gestionnaires de projets à gérer efficacement leurs communautés.

Github a subi de grosses pressions venant des développeurs qui gèrent certains projets, ces pressions incluent une lettre ouverte collective intitulée « Cher Github », principalement issue de la communauté Javascript. Cette lettre explique : « Beaucoup sont frustrés. Certains parmi nous qui déploient des projets très populaires sur Github se sentent totalement ignoré par vous ». La lettre inclut une liste de requêtes pour l’amélioration de produits, qui pourrait les aider à gérer plus efficacement leurs projets.

Github se confronte de plus en plus à des difficultés largement documentées dans les médias. Auparavant, l’entreprise était connue pour sa hiérarchie horizontale, sans aucun manager ni directive venant d’en haut. Les employés de Github avaient aussi la liberté de choisir de travailler sur les projets qu’ils souhaitaient. Ces dernières années, tandis que Github s’est développée pour atteindre presque 500 employés, l’entreprise a réorienté sa stratégie vers une orientation plus commerciale en recrutant des équipes de vente et des dirigeants, insérés dans un système hiérarchique plus traditionnel. Cette transition d’une culture décentralisée vers plus de centralité s’est faite dans la douleur chez Github : au moins 10 dirigeants ont quitté l’organisation durant les quelques mois de l’hiver 2015-2016, ces départs incluant l’ingénieur en chef, le directeur des affaires financières, le directeur stratégique et le directeur des ressources humaines. En raison de ces conflits internes, Github n’a toujours pas pris position publiquement pour jouer un rôle de promoteur de l’open source et assumer un leadership à même de résoudre les questions pressantes autour de l’open source, mais le potentiel est bel et bien là.

Pour le capital-risque, abordé précédemment, il y a un enjeu particulier dans l’avenir des infrastructures numériques. Comme les outils des développeurs aident les entreprises du secteur technologique à créer plus rapidement et plus efficacement, meilleurs sont les outils, meilleures sont les startups, meilleure sera la rentabilité du capital-risque. Néanmoins, l’infrastructure, d’un point de vue capitaliste, n’est en rien limitée à l’open source mais plus largement focalisée sur les plateformes qui aident d’autres personnes à créer. C’est pour cela que les investissements dans Github ou npm, qui sont des plateformes qui aident à diffuser du code source, ont un sens, mais tout aussi bien les investissements dans Slack, une plateforme de travail collaboratif que les développeurs peuvent utiliser pour construire des applications en ligne de commande connectées à la plateforme (à ce propos, le capital-risque a constitué un fonds de 80 millions dédié au support de projets de développement qui utilisent Slack). Même si le capital-risque apprécie les mécaniques sous-jacentes de l’infrastructure, il est limité dans ses catégories d’actifs : un capitaliste ne peut pas investir dans un projet sans modèle économique.

Enfin, les institutions universitaires ont joué un rôle historique éminent dans le soutien aux infrastructures numériques, tout particulièrement le développement de nouveaux projets. Par exemple, LLVM, un projet de compilateur pour les langages C et C++, a démarré en tant que projet de recherche au sein de l’Université de l’Illinois, à Urbana-Champaign. Il est maintenant utilisé par les outils de développement de Mac OS X et iOS d’Apple, mais aussi dans le kit de développement de la Playstation 4 de Sony.

Un autre exemple, R, un langage de programmation répandu dans la statistique assistée par ordinateur et l’analyse de données, a été d’abord écrit par Robert Gentleman et Ross Ihaka à l’Université d’Auckland. R n’est pas uniquement utilisé par des entreprises logicielles comme Facebook ou Google, mais aussi par la Bank of America, l’Agence américaine des produits alimentaires et médicamenteux et le Service météorologique national américain, entre autres.

Quelques universités emploient également des programmeurs qui ont alors la liberté de travailler à des projets open source. Par exemple, le protocole d’heure réseau ou NTP (Network Time Protocol) utilisé pour synchroniser le temps via Intrenet, fut d’abord développé par David Mills, maintenant professeur émérite de l’université du Delaware — le projet continuant à être maintenu par un groupe de volontaires conduit par Harlan Stenn. Bash, l’outil de développement dont nous parlions dans un chapitre précédent, est actuellement maintenu par Chet Ramsay, qui est employé par le département des technologies de l’information de l’université Case Western.

Les institutions universitaires ont le potentiel pour jouer un rôle important dans le soutien de nouveaux projets, parce que cela coïncide avec leurs missions et types de donation, mais elles peuvent aussi manquer de la réactivité nécessaire pour attirer les nouveaux programmeurs open source. NumFOCUS est un exemple d’une fondation 501(c)(3) qui soutient les logiciels scientifiques open source à travers des donations et  parrainages financiers. Le modèle de la fondation externe peut aider à fournir le soutien dont les logiciels scientifiques ont besoin dans un contexte d’environnement universitaire. Les fondations Alfred P. Sloan et Gordon & Betty Moore expérimentent aussi des manières de connecter les institutions universitaires avec les mainteneurs de logiciels d’analyse des données, dans le but de soutenir un écosystème ouvert et durable.

Dans ce onzième chapitre de son ouvrage Des routes et des ponts que l’équipe Framalang vous traduit semaine après semaine (si vous avez raté le début), Nadia Eghbal aborde le problème endémique des infrastructures numériques open source, leur manque de ressources humaines pérennes : entre ceux qui s’y consacrent à corps perdu et s’arrêtent au bord du burnout, les entreprises qui profitent des ressources sans jamais contribuer en retour, ceux qui se lancent ingénument dans le développement sans notion bien nette de sécurité, ceux qui ne peuvent contribuer que sur un temps libre limité… Des témoignages sur ces situations et d’autres encore ont été recueillis dans ce chapitre.

Comme le souligne l’autrice, cette situation bancale a pour conséquence un coût important en termes d’argent et de sécurité pour l’ensemble de l’industrie numérique qui puise abondamment dans l’infrastructure numérique open source.

Négliger les infrastructures a un coût caché

Traduction Framalang : Piup, jums, Penguin, serici, xi, Asta, Diane, glissière de sécurité, Luc, goofy, lyn

Comme nous l’avons vu, l’infrastructure numérique est un constituant essentiel du monde actuel. Notre société repose sur les logiciels, et ces logiciels s’appuient de plus en plus sur une infrastructure qui utilise des méthodologies open source. Dans la mesure où nous prenons peu d’initiatives pour comprendre et pérenniser notre infrastructure numérique, que mettons-nous en péril ?
Ne pas réinvestir dans l’infrastructure numérique présente des dangers que l’on peut classer en deux catégories : les coûts directs et les coûts indirects.

Les coûts directs

Les coûts directs sont les bogues non détectés et les vulnérabilités de sécurité qui peuvent être exploitées à des fins malveillantes, ou qui mènent à des interruptions imprévues dans le fonctionnement des logiciels. Ces coûts sont fortement ressentis et causent des problèmes qui doivent être résolus immédiatement.

Les coûts indirects

Les coûts indirects se traduisent par exemple par la perte de main-d’œuvre qualifiée, ainsi qu’une croissance faible et peu d’innovation. Même si ces coûts ne sont pas immédiatement perceptibles, ils représentent une valeur sociale difficile à évaluer.

Bogues, failles de sécurité et interruptions du service

L’introduction de ce rapport relatait les détails de la faille de sécurité Heartbleed, qui a été découverte en avril 2014 dans une bibliothèque logicielle appelée OpenSSL. Du fait de son usage généralisé, notamment pour le fonctionnement de nombreux sites web majeurs, Heartbleed a largement attiré l’attention du public sur le problème des failles de sécurité des logiciels.

En septembre 2014, une autre faille majeure a été découverte dans un autre outil essentiel appelé Bash. Bash est inclus dans des systèmes d’exploitation populaires tels que Linux et Mac OS, ce qui fait qu’il est installé sur 70 % des machines connectées à internet.

L’ensemble de bugs de sécurité, surnommés « ShellShock », peuvent être exploités pour permettre un accès non autorisé à un système informatique. Les vulnérabilités étaient restées non-détectées pendant au moins une décennie. Bash a été créé à l’origine par un développeur appelé Brian Fox en 1987, mais depuis 1992 il est maintenu par un seul développeur, Chet Ramey, qui travaille comme architecte technique senior à la Case Western University dans l’Ohio.

Un autre projet, OpenSSH, fournit une suite d’outils de sécurité dont l’usage est largement répandu sur internet. Des développeurs ont trouvé de multiples failles dans son code qui ont pu être prises en charge et corrigées, y compris celle de juillet 2015, qui permettait aux attaquants de dépasser le nombre maximal d’essais sur les mots de passe, et celle de janvier 2016, qui laissait fuiter les clefs de sécurité privées.

L’un des aspects du problème est que beaucoup de projets sont des outils anciens, développés au départ par un ou plusieurs développeurs passionnés, qui ont par la suite manqué de ressources pour gérer le succès de leur projet. Avec le temps, les contributions diminuent et les acteurs restants se lassent et s’en vont, mais pour autant le projet est toujours activement utilisé, avec seulement une ou deux personnes tâchant de le maintenir en vie.

Un autre problème croissant dans le paysage des logiciels actuel, où l’on voit tant de jeunes développeurs inexpérimentés, c’est que les concepts de sécurisation ne sont pas enseignés ou pas considérés comme prioritaires. Les nouveaux développeurs veulent simplement écrire du code qui marche. Ils ne savent pas faire un logiciel sécurisé, ou pensent à tort que le code public qu’ils utilisent dans la sécurité de leurs programmes a été vérifiée. Même les bonnes pratiques de divulgation sécurisée ou de gestion des failles ne sont généralement pas enseignées ni comprises. La sécurité ne devient un enjeu que lorsque le code d’un développeur a été compromis.

Christopher Allen a coécrit la première version du protocole de transfert sécurisé TLS (Transport Layer Security), dont les versions successives sont devenues un standard utilisé quasiment universellement en ligne, y compris sur des sites comme Google, Facebook ou YouTube. Bien que le protocole soit devenu un standard, Christophe parle ainsi de ses origines :

« En tant que co-auteur de TLS, je n’aurais pas prédit que 15 ans plus tard la moitié d’Internet utiliserait une implémentation de TLS maintenue par un ingénieur à quart-temps. C’est ce manque de maintenance qui a conduit au bug tristement célèbre de Heartbleed. Je raconte aujourd’hui cette anecdote à mes collègues qui travaillent sur les crypto-monnaies pour les avertir que leur chiffrage, ultra moderne aujourd’hui, pourrait  être ’dépassé’ dans 10 ans et subir le même sort, le projet n’étant plus aussi passionnant, et leur travail acharné risquerait d’être compromis. »

En définitive, la stabilité de nos logiciels repose sur la bonne volonté et la coopération de centaines de développeurs, ce qui représente un risque significatif. La fragilité de notre infrastructure numérique a récemment été démontrée par un développeur nommé Azer Koçulu.
Azer, un développeur Node.js, hébergeait un certain nombre de bibliothèques sur un gestionnaire de paquets nommé npm. Après un conflit avec npm sur la propriété intellectuelle d’un de ses projets, Azer, mécontent de l’issue du conflit, décida de supprimer toutes les publications qu’il avait pu faire sur npm.

L’une de ces bibliothèques, left-pad, avait été réutilisée dans des centaines d’autres projets. Même s’il ne s’agissait que de quelques lignes de code, en supprimant le projet left-pad, Azer a « cassé » les algorithmes d’innombrables protocoles logiciels développés par d’autres. La décision d’Azer a provoqué tant de problèmes que npm a pris la décision sans précédent de republier sa bibliothèque, contre la volonté d’Azer, afin de restaurer les fonctionnalités offertes par le reste de l’écosystème.

Npm a aussi revu sa politique pour qu’il soit plus difficile pour les développeurs de retirer leurs bibliothèques sans avertissement, reconnaissant ainsi que les actions d’un individu peuvent en affecter négativement beaucoup d’autres.

Les logiciels ne reçoivent pas la maintenance nécessaire dont ils ont besoin

Construire une infrastructure numérique de façon désorganisée implique que tout logiciel sera construit plus lentement et moins efficacement. L’histoire de l’infrastructure Python en fournit un bon exemple.

L’un des importants projets d’infrastructure pour les développeurs Python se nomme Setuptools. Setuptools fournit un ensemble d’outils qui rendent le développement en Python plus simple et plus standardisé.
Setuptools a été écrit en 2004, par le développeur PJ Eby. Pendant les quatre années qui ont suivi, l’outil a été largement adopté. Néanmoins, Setuptools était difficile à installer et à utiliser, et Eby était très peu réceptif aux contributions et aux corrections apportées par d’autres, car il voulait, en tant que concepteur, avoir le dernier mot sur Setuptools. En 2008, un groupe de développeurs conduits par Tarek Ziade a décidé de forker le projet pour obliger Eby à faire des améliorations. Ils ont appelé le nouveau projet « Distribute ». En 2013, les deux projets ont fusionné dans Setuptools.
Ce long désaccord a néanmoins souligné à la fois l’état douteux des outils de l’infrastructure de Python, et la difficulté de mettre en œuvre des améliorations, notamment parce que personne ne se consacrait aux problèmes de la communauté ni ne désirait s’en occuper.

Les outils de Python ont commencé à s’améliorer quand le groupe de travail Python Packaging Authority (PyPA) s’est formé pour se consacrer spécifiquement à définir de meilleurs standards pour le paquetage. Un développeur, Donald Stufft, fit des outils de paquetage Python le cœur de son travail et fut engagé par HP (devenu HPE) en mai 2015 pour poursuivre son travail (son parcours sera évoqué plus tard dans ce rapport).

Un autre exemple intéressant est celui de RubyGems.org, un site web utilisé par la plupart des développeurs Ruby pour héberger leurs bibliothèques Ruby. Ruby a été utilisé pour bâtir des sites web majeurs comme Twitter, AirBnB, YellowPages et GitHub lui-même. En 2013, une faille de sécurité de RubyGems.org a été découverte, mais elle ne fut pas réparée avant plusieurs jours, parce que RubyGems.org était entièrement maintenue par des bénévoles. Les bénévoles pensaient régler le problème le week-end, mais pendant ce temps, quelqu’un d’autre a découvert la faille et a piraté le serveur de RubyGems.org. Après l’attaque, les serveurs ont dû être entièrement reconfigurés. Plusieurs bénévoles ont pris sur leur temps de travail, et certains ont même pris des jours de congé, afin de remettre RubyGems.org en état de marche le plus vite possible.

Comme RubyGems.org est un élément d’infrastructure critique, la faille de sécurité affectait par rebond beaucoup de développeurs et d’entreprises. L’incident a mis en lumière le fait qu’un travail fondé uniquement sur la base du volontariat limitait les garanties de sécurité et de fiabilité que l’on pouvait offrir sur une infrastructure logicielle importante. Des dizaines de développeurs se mobilisèrent de façon « bénévole » pendant l’incident parce que le problème affectait directement leur emploi salarié.

Malheureusement, aucun d’entre eux n’avait l’expérience requise pour être utile, et aucun d’entre eux n’a continué à offrir son aide une fois les serveurs réparés. En 2015, une organisation nommée Ruby Together a été formée pour aider à financer la maintenance et le développement de l’infrastructure Ruby, entre autres RubyGems.org, en sollicitant des entreprises comme sponsors.

La perte de main-d’œuvre qualifiée

Comme dans beaucoup de communautés de bénévoles, le « burnout » est commun parmi les contributeurs open source, qui se retrouvent à répondre aux requêtes d’utilisateurs individuels ou d’entreprises, pour un travail sans compensation. Beaucoup de développeurs ont des anecdotes où des entreprises les sollicitaient pour du travail gratuit. Daniel Roy Greenfield, développeur Django et Python, a écrit :

« J’ai personnellement eu des demandes pour du travail non-payé (les discussions pour payer le travail n’aboutissent jamais) par des entreprises à haut profit, grandes ou petites, pour [mes projets]. Si je ne réponds pas dans les temps convenus, si je n’accepte pas une pull request merdique, on va me mettre une étiquette de connard. Il n’y a rien de pire que d’être face à des développeurs du noyau Python/PyPA travaillant pour Redhat [sic], qui exigent de toi un travail non payé tout en critiquant ce qu’ils considèrent comme les insuffisances de ton projet, pour te pourrir ta journée et plomber ta foi en l’open source. »

(Red Hat est une multinationale du logiciel avec un revenu annuel excédant les 2 milliards d’euros, qui vend des logiciels open source à des clients d’entreprise. Du fait de la nature de leur entreprise, les employés de Red Hat utilisent et contribuent à de nombreux projets open source : en un sens, Red Hat est devenu la tête d’affiche de l’open source dans le monde de l’entreprise. Nous reparlerons de son succès financier plus tard dans ce rapport).

Read the Docs, service d’hébergement de documentation technique précédemment mentionné, annonce explicitement sur son site qu’il ne s’occupe pas de l’installation personnalisée dans les entreprises ou chez les particuliers.

L’un des mainteneurs, Eric Holscher, va jusqu’à faire ce commentaire :
« Je suis à peu près sûr que Read the Docs n’a aucun intérêt à être open source, vu que les utilisateurs privés ne contribuent jamais en retour, et se contentent de demander une assistance gratuite. »
Maquess, le contributeur OpenSSL, a tenu un discours acerbe à propos des requêtes récurrentes sur ses posts qui parlent de financement :

« C’est à vous que je pense, entreprises du Fortune 1000. Vous qui incluez OpenSSL dans vos firewall/dispositifs/cloud/produits financiers ou de sécurité, tous ces produits que vous vendez à profit, ou que vous utilisez pour vos infrastructures et communications internes. Vous qui n’avez pas besoin de financer une équipe interne de programmeurs pour se débattre avec du code crypté, puis qui nous harcelez pour obtenir une assistance gratuite quand vous réalisez que vous êtes incapables de l’utiliser. Vous qui n’avez jamais levé le petit doigt pour contribuer à la communauté open source qui vous a fait ce cadeau. Les concernés se reconnaîtront. Certains développeurs choisissent d’arrêter de maintenir leurs projets parce qu’ils n’ont plus assez de temps à y consacrer, et espèrent que quelqu’un d’autre prendra le relais. Pendant ce temps, les entreprises, les gouvernements et les individus dépendent de ces bibliothèques pour leur bon fonctionnement, inconscients des enjeux sous-jacents. »

David Michael Ross, ingénieur manager dans une agence web, a écrit au sujet de son expérience :

« Pour moi, c’est là que le bât blesse.  […] On sait qu’on a créé quelque chose gratuitement, par passion, et on voit ce flux infini de personnes qui crient « plus ! encore plus ! » et qui se mettent en colère quand on ne traite pas leur cas particulier.
Il y avait mon numéro de téléphone sur l’un de mes sites personnels pour que mes amis puissent me joindre. Je l’ai enlevé au bout d’une semaine parce que des gens m’appelaient à toute heure de la journée pour de l’assistance sur les plugins, alors qu’il y a un forum consacré à ça. Il n’y a rien de fondamentalement méchant là-dedans, c’est juste que c’est usant. On se met à avoir peur de vérifier ses mails ou de répondre au téléphone. »

Ryan Bigg, qui écrit de la documentation technique pour le framework Ruby on Rails, a annoncé en novembre 2015 qu’il renonçait à tout travail open source :

« Je n’ai plus le temps ni l’énergie de m’investir dans l’open source. Je ne retire strictement aucun revenu de mon travail open source, ce qui veut dire que le travail que je fais là, c’est du temps que je pourrais consacrer à des activités perso, ou à écrire. Ce n’est pas justifié d’attendre de moi que je travaille encore, en dehors de mon emploi salarié, sans que je sois honnêtement rétribué pour ça (en temps ou en argent). C’est aussi une recette qui a de bonnes chances de me conduire au burnout ou de me rendre juste globalement aigri.

Par ailleurs, la perte de main-d’œuvre qualifiée dans l’open source, ce n’est pas seulement les contributeurs qui démissionnent, c’est aussi ceux qui n’ont jamais contribué du tout. »

Il existe très peu de statistiques sur la démographie des contributeurs open source, ce qui est déjà révélateur en soi. Une analyse récente de GitHub a révélé que seulement 5,4% des contributeurs open source étaient des femmes, qui occupent pourtant environ 15 à 20% des postes techniques dans l’ensemble des entreprises de logiciels.

L’une des raisons qui font que les contributeurs open source sont un groupe remarquablement plus homogène que le secteur de la technologie dans son ensemble, c’est qu’ils ont besoin de temps et d’argent pour apporter dans un premier temps des contributions significatives. Ces contraintes empêchent des contributeurs par ailleurs qualifiés d’entrer dans cet espace.
David Maclver, créateur de Hypothésis, une bibliothèque Python qui sert à tester des applications logicielles, explique pourquoi il a pu passer autant de temps sur le projet :

« J’ai pu le faire seulement parce que j’avais le temps et l’argent pour le faire. J’avais le temps parce que j’étais obsessionnel, je n’avais personne à charge, et je n’avais pas d’emploi. Je pouvais me permettre de ne pas avoir d’emploi parce que j’avais de l’argent. J’avais de l’argent parce que pendant la dernière moitié de l’année passée, je touchais un salaire deux fois plus élevé que d’habitude, en dépensant deux fois moins que d’habitude, et je traversais une dépression qui me rendait trop borderline pour avoir envie de dépenser mon argent dans quoi que ce soit d’intéressant. Ce ne sont pas des conditions qu’on peut raisonnablement exiger de quelqu’un. […] Est-ce qu’on pourrait produire un logiciel de qualité en moins de temps que ça, en ne travaillant que sur du temps libre ? J’en doute. »

Cory Benfield, un développeur pour les fonctions de base de Python, écrit :

« De manière générale, les personnes qui ne sont pas des hommes cisgenres, hétérosexuels, blancs, de classe moyenne, et anglophones sont moins susceptibles de pouvoir assumer les risques financiers accrus associés à l’absence d’emploi stable. Cela signifie que ces personnes ont vraiment besoin d’un salaire régulier pour pouvoir contribuer le plus efficacement possible. Et nous avons besoin de leur contribution : des équipes diversifiées font un meilleur travail que des équipes homogènes. »

Charlotte Spencer, qui contribue au framework logiciel Hoodie et au système de bases de données PouchDB, fait écho à cette opinion :

« Toutes mes contributions sont purement bénévoles. Je n’en retire pas d’argent, même si j’aimerais beaucoup pouvoir. J’ai demandé à des vétérans de l’open source s’ils étaient payés et ce n’est pas le cas, ce qui m’a découragé d’essayer quoi que ce soit (si ces gens-là ne sont pas payés, pourquoi le serais-je ?). J’y consacre la plus grande partie de mon temps libre, mais j’essaie d’en faire moins parce que ça envahissait trop ma vie. »

Jessica Lord, développeuse, a contribué activement à l’open source tout en travaillant à Code for America, une organisation à but non-lucratif qui soutient la technologie dans le secteur public. Urbaniste de formation, elle insiste sur le fait qu’elle n’avait « pas de diplôme en informatique, pas d’expérience formelle en programmation, mais un portfolio GitHub ».

Ses contributions régulières attirèrent l’attention de la plate-forme GitHub elle-même, pour qui elle travaille désormais. Cependant, Jessica note qu’elle a pu contribuer à l’open source grâce à un concours de circonstances « particulier » : elle a accepté une baisse de salaire pour travailler à Code for America, utilisé toutes ses économies, travaillé « presque non-stop » sur des projets open source, et bénéficié d’une communauté de soutiens.

À propos du manque de diversité dans l’open source, Jessica écrit:

« La valeur des savoirs communs ne peut être surestimée. Nous devons faire mieux. Nous avons besoin des idées de tout le monde. C’est le but que nous devrions chercher à atteindre. Il est nécessaire que l’open source soit ouvert à tous. Pas seulement aux privilégiés ou même aux seuls développeurs. »

Ce dernier point soulevé par Jessica Lord est révélateur : permettre à des profils plus divers de participer à l’open source peut aider à pérenniser l’open source en elle-même. D’un point de vue fonctionnel, la grande majorité des contributeurs open source sont des développeurs, mais beaucoup d’autres rôles sont nécessaires pour gérer les projets d’ampleur, comme la rédaction, la gestion de projet ou la communication. Les projets open source ne sont pas différents des autres types d’organisations, y compris les startups où l’on a besoin de personnes se chargeant de l’administration, du marketing, du design, etc., qui sont autant de fonctions nécessaires au fonctionnement de base d’une structure. C’est en partie parce que la culture open source repose principalement sur les développeurs que la pérennité financière est si rarement l’objet de discussions et d’actions concrètes.

Enfin, l’homogénéité des contributeurs open source impacte les efforts en faveur de la diversité dans le monde de la technologie au sens large, puisque l’open source est étroitement lié à l’embauche. En effet, comme nous l’avons remarqué plus haut, beaucoup d’employeurs utilisent les contributions open source, notamment les profils GitHub, pour découvrir leurs futurs employés potentiels ou pour vérifier les qualifications d’un candidat. Les employeurs qui se fient ainsi essentiellement aux preuves de contributions open source ne recrutent que parmi un vivier de candidats extrêmement restreint.

Ashe Dryden, dans un essai important intitulé L’Éthique du travail non payé et la Communauté OSS, expliquait :

« Juger que quelqu’un est un bon programmeur en se basant uniquement sur le code qu’il rend disponible publiquement, c’est exclure bien plus que les gens marginaux. C’est aussi exclure quiconque n’est pas autorisé à publier son code publiquement pour des raisons de licence ou de sécurité. Cela concerne également un grand nombre de travailleurs freelance ou de contractuels qui, pour des raisons légales, n’ont pas le droit de revendiquer publiquement leur participation à un projet (par exemple s’ils ont signé un accord de confidentialité). Dans une industrie où on lutte pour dénicher assez de talents, pourquoi limitons-nous artificiellement le spectre des candidats ? » (source)

Comment atténuer ou éviter certains des coûts qui s’imposent aux personnes qui participent à l’élaboration d’infrastructures numériques aujourd’hui ? Pour commencer, nous analyserons comment les projets d’infrastructure sont actuellement financés.