Version classiqueVersion mobile
OpenEdition Books

Sur quoi reposent nos infrastructures numériques ?

 | 
Nadia Eghbal

Défis à relever

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

Texte intégral

1Comme 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 ?

2Ne 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 : les coûts directs sont les bugs 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 que par 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.

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

3L’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.

4En 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 à Internet1.

5L’ensemble des bugs de sécurité, surnommé « ShellShock », peut être exploité 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éé en 1987 par un développeur appelé Brian Fox, 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.

6Un 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 20152, 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 clés de sécurité privées3.

7L’un des aspects du problème est que beaucoup de projets sont des outils anciens, conçus 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 qui tâchent de le maintenir en vie.

8Un 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é. 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.

  • 4 Christopher Allen, article sur Medium.com, 16/01/2016.

9Christopher 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, Christopher parle ainsi de ses origines4 :

En tant que coauteur de TLS, je n’aurais pas prédit que quinze 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 dix ans et subir le même sort, le projet n’étant plus aussi passionnant, et leur travail acharné risquerait d’être compromis.

10En 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.

  • 5 Azer Koçulu, « I’ve Just Liberated My Modules », Medium.com, 22/03/2016.

11Azer, un développeur Node.js, hébergeait un certain nombre de bibliothèques dans un gestionnaire de paquets nommé npm5. Après un conflit avec npm sur la propriété intellectuelle d’un de ses projets, Azer, mécontent du dénouement, décida de supprimer toutes les publications qu’il avait pu faire sur npm.

12L’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ème6.

13Npm 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’autres7.

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

14Construire 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.

15L’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é.

16Setuptools a été écrit en 2004, par le développeur P.J. 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.

17Ce 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.

  • 8 Source : Entretiens par courriel avec Russell Keith-Magee et Hynek Schlawac.

18Les 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 cet ouvrage8).

19Un 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.

20Comme 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é.

  • 9 Source : Entretiens par courriel et au téléphone avec André Arko. Merci à lui.

21Malheureusement, 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 sponsors9.

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

22Comme dans beaucoup de communautés de bénévoles, le burn-out est courant 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 écrit10 :

J’ai personnellement eu des demandes pour du travail non payé (les discussions pour payer le travail n’aboutissent jamais) par des entreprises aux profits considérables, 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 coller une étiquette de connard. Il n’y a rien de pire que d’être face à des développeurs du noyau Python/PyPA travaillant pour Red Hat (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.

23(Red Hat est une multinationale du logiciel avec un revenu annuel excédant les 2 milliards d’euros11, 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 cet ouvrage.)

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

  • 14 Eric Holscher, Tweet, sur Twitter.com, datée du 19/01/2016.

25L’un des mainteneurs, Eric Holscher, va jusqu’à faire ce commentaire14 : « 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. »

26Marquess, le contributeur OpenSSL, a tenu un discours acerbe à propos des requêtes récurrentes sur ses posts qui parlent de financement15 :

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.

  • 16 Commentaire de csixty4 sur Hacker News, sur le fil « The reason people burn out on open source ».

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

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.

  • 17 Ryan Bigg, « Open Source Work », site personnel Ryanbigg.com, 16/11/2015.

28Ryan 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 source17 :

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 burn-out ou de me rendre juste complètement aigri.

29Par 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.

  • 18 5,4 %, c'est le pourcentage de contributrices ayant soumis plus de 10 contributions. Voir Breanden (...)

30Il 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 montré que seulement 5,4 % des contributeurs open source étaient des femmes18, qui occupent pourtant environ 15 à 20 % des postes techniques dans l’ensemble des entreprises de logiciels.

31L’une des raisons qui fait 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 tout d'abord des contributions significatives. Ces contraintes empêchent des contributeurs par ailleurs qualifiés d’entrer dans cet espace.

32David Maclver, créateur de Hypothésis, une bibliothèque Python qui sert à tester des applications logicielles, explique19 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.

  • 20 Source : entretien par courriel avec Cory Benfield.

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

  • 21 Dans les études de genre, cisgenre décrit un type d'identité de genre où le genre ressenti d'une p (...)

De manière générale, les personnes qui ne sont pas des hommes cisgenres21, 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.

  • 22 Source : entretien par courriel avec Charlotte Spencer.

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

Toutes mes contributions sont purement bénévoles. Je n’en retire pas d’argent, même si j’aimerais beaucoup pouvoir le faire. 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 personnes-là ne sont pas payées, 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.

35Jessica 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 fait23 qu’elle n’avait « pas de diplôme en informatique, pas d’expérience formelle en programmation, mais un portfolio GitHub ».

36Ses contributions régulières attirèrent l’attention de la plateforme 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.

37À 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.

38Ce 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 strates 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.

39Enfin, 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.

40Ashe Dryden, dans un essai important intitulé L’éthique du travail non payé et la communauté OSS, expliquait24 :

Juger que quelqu’un est un bon programmeur en s'appuyant uniquement sur le code qu’il rend disponible publiquement, c’est exclure bien plus que les 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 ?

41Comment 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.

Notes

1 Nicole Perlroth, « Security experts expect "Shellshock" software bug to be significant », Gadgets Now, 28/09/2014.

2 Doug Drinkwater, « OpenSSH flaw opens the door to brute force attackers », SC Media, 24/07/2015.

3 Dan Goodin, « Bug that can leak crypto keys just fixed in widely used OpenSSH », Ars Technica, 01/04/2016.

4 Christopher Allen, article sur Medium.com, 16/01/2016.

5 Azer Koçulu, « I’ve Just Liberated My Modules », Medium.com, 22/03/2016.

6 Chris Williams, « How one developer just broke Node, Babel and thousands of projects in 11 lines of JavaScript », The Register, 23/03/2016.

7 Npm, « kik, left-pad, and npm », The Npm Blog, 23/03/2016.

8 Source : Entretiens par courriel avec Russell Keith-Magee et Hynek Schlawac.

9 Source : Entretiens par courriel et au téléphone avec André Arko. Merci à lui.

10 Commentaire de pydanny sur Paying the piper (projet GitHub), 16/10/2015.

11 Barb Darrow, « Red Hat Is Now a $2 Billion Open-Source Baby », Fortune, 23/03/2016.

12 Voir partie 2, chapitre 3.

13 Read the Docs, Read the Docs Open Source Philosophy.

14 Eric Holscher, Tweet, sur Twitter.com, datée du 19/01/2016.

15 Stevem, « Of Money, Responsibility, and Pride », Speeds and Feeds, 12/04/2014.

16 Commentaire de csixty4 sur Hacker News, sur le fil « The reason people burn out on open source ».

17 Ryan Bigg, « Open Source Work », site personnel Ryanbigg.com, 16/11/2015.

18 5,4 %, c'est le pourcentage de contributrices ayant soumis plus de 10 contributions. Voir Breanden Beneschott, « Is Open Source Open to Women? », Toptal, septembre 2015.

19 David R. MacIver, « It’s OK for your open source library to be a bit shitty », 08/04/2015.

20 Source : entretien par courriel avec Cory Benfield.

21 Dans les études de genre, cisgenre décrit un type d'identité de genre où le genre ressenti d'une personne correspond au genre qui lui a été assigné à la naissance. Voir « Cisgenre », sur Wikipédia.

22 Source : entretien par courriel avec Charlotte Spencer.

23 Jessica Lord, « Privilege, Community and Open Source », 18/05/2015.

24 Ashe Dryden, « The Ethics of Unpaid Labor and the OSS Community », 13/11/2013.

Acheter

Volume papier

Chargement

Unavailable