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.

Une question épineuse pour les projets libres et open source est leur maintenance à long terme, et bien évidemment les ressources, tant financières qu’humaines, que l’on peut y consacrer. Tel est le sujet qu’aborde ce nouveau chapitre de l’ouvrage de Nadia Eghbal Des routes et des ponts que le groupe Framalang vous traduit semaine après semaine (si vous avez raté les épisodes précédents)

Elle examine ici une série de cas de figures en fonction de l’origine de l’origine projet.

Comment les projets d’infrastructure numérique sont-ils gérés et maintenus ?

TraductionFramalang : Diane, Penguin, Asta, Rozmador, Lumibd, jum-s, goofy, salade, AFS, Théo

Nous avons établi que les infrastructures numériques sont aussi nécessaires à la société moderne que le sont les infrastructures physiques. Bien qu’elles ne soient pas sujettes aux coûts élevés et aux obstacles politiques auxquels sont confrontées ces dernières, leur nature décentralisée les rend cependant plus difficiles à cerner. Sans une autorité centrale, comment les projets open source trouvent-ils les ressources dont ils ont besoin ?

En un mot, la réponse est différente pour chaque projet. Cependant, on peut identifier plusieurs lieux d’où ces projets peuvent  émaner : au sein d’une entreprise, via une startup, de développeurs individuels ou collaborant en communauté.

Au sein d’une entreprise

Parfois, le projet commence au sein d’une entreprise. Voici quelques exemples qui illustrent par quels moyens variés un projet open source peut être soutenu par les ressources d’une entreprise :

Go, le nouveau langage de programmation évoqué précédemment, a été développé au sein de Google en 2007 par les ingénieurs Robert Griesemer, Rob Pike, et Ken Thompson, pour qui la création de Go était une expérimentation. Go est open source et accepte les contributions de la communauté dans son ensemble. Cependant, ses principaux mainteneurs sont employés à plein temps par Google pour travailler sur le langage.

React est une nouvelle bibliothèque JavaScript dont la popularité grandit de jour en jour.
React a été créée par Jordan Walke, ingénieur logiciel chez Facebook, pour un usage interne sur le fil d’actualités Facebook. Un employé d’Instagram (qui est une filiale de Facebook) a également souhaité utiliser React, et finalement, React a été placée en open source, deux ans après son développement initial.
Facebook a dédié une équipe d’ingénieurs à la maintenance du projet, mais React accepte aussi les contributions de la communauté publique des développeurs.

Swift, le langage de programmation utilisé pour iOS, OS X et les autres projets d’Apple, est un exemple de projet qui n’a été placé en open source que récemment. Swift a été développé par Apple en interne pendant quatre ans et publié en tant que langage propriétaire en 2014. Les développeurs pouvaient utiliser Swift pour écrire des programmes pour les appareils d’Apple, mais ne pouvaient pas contribuer au développement du cœur du langage. En 2015, Swift a été rendu open source sous la licence Apache 2.0.

Pour une entreprise, les incitations à maintenir un projet open source sont nombreuses. Ouvrir un projet au public peut signifier moins de travail pour l’entreprise, grâce essentiellement aux améliorations de la collaboration de masse.
Cela stimule la bonne volonté et l’intérêt des développeurs, qui peuvent alors être incités à utiliser d’autres ressources de l’entreprise pour construire leurs projets.

Disposer d’une communauté active de programmeurs crée un vivier de talents à recruter. Et parfois, l’ouverture du code d’un projet aide une entreprise à renforcer sa base d’utilisateurs et sa marque, ou même à l’emporter sur la concurrence. Plus une entreprise peut capter de parts de marché, même à travers des outils qu’elle distribue gratuitement, plus elle devient influente. Ce n’est pas très différent du concept commercial de « produit d’appel ».

Même quand un projet est créé en interne, s’il est open source, alors il peut être librement utilisé ou modifié selon les termes d’une licence libre, et n’est pas considéré comme relevant de la propriété intellectuelle de l’entreprise au sens traditionnel du terme. De nombreux projets d’entreprise utilisent des licences libres standard qui sont considérées comme acceptables par la communauté des développeurs telles que les licences Apache 2.0 ou BSD. Cependant, dans certains cas, les entreprises ajoutent leurs propres clauses. La licence de React, par exemple, comporte une clause additionnelle qui pourrait potentiellement créer des conflits de revendications de brevet avec les utilisateurs de React.

En conséquence, certaines entreprises et individus sont réticents à utiliser React, et cette décision est fréquemment décrite comme un exemple de conflit avec les principes de l’open source.

Via une startup

Certains projets d’infrastructures empruntent la voie traditionnelle de la startup, ce qui inclut des financements en capital-risque. Voici quelques exemples :
Docker, qui est peut-être l’exemple contemporain le plus connu, aide les applications logicielles à fonctionner à l’intérieur d’un conteneur. (Les conteneurs procurent un environnement propre et ordonné pour les applications logicielles, ce qui permet de les faire fonctionner plus facilement partout). Docker est né en tant que projet interne chez dotCloud, une société de Plate-forme en tant que service (ou PaaS, pour  platform as a service en anglais), mais le projet est devenu si populaire que ses fondateurs ont décidé d’en faire la principale activité de l’entreprise. Le projet Docker a été placé en open source en 2013. Docker a collecté 180 millions de dollars, avec une valeur estimée à plus d’1 milliard de dollars.

Leur modèle économique repose sur du support technique, des projets privés et des services. Les revenus de Docker pour l’année 2014 ne dépassaient pas 10 millions de dollars.

Npm est un gestionnaire de paquets sorti en 2010 pour aider les développeurs de Node.js à partager et à gérer leurs projets. Npm a collecté près de 11 millions de dollars de financements depuis 2014 de la part de True Ventures et de Bessemer Ventures, entre autres. Leur modèle économique se concentre sur des fonctionnalités payantes en faveur de la vie privée et de la sécurité.

Meteor est un framework JavaScript publié pour la première fois en 2012. Il a bénéficié d’un programme d’incubation au sein de Y Combinator, un prestigieux accélérateur de startups qui a également été l’incubateur d’entreprises comme AirBnB et Dropbox. À ce jour, Meteor a reçu plus de 30 millions de dollars de financements de la part de firmes comme Andreessen Horowitz ou Matrix Partners. Le modèle économique de Meteor se base sur une plateforme d’entreprise nommée Galaxy, sortie en Octobre 2015, qui permet de faire fonctionner et de gérer les applications Meteor.

L’approche basée sur le capital-risque est relativement nouvelle, et se développe rapidement.
Lightspeed Venture Partners a constaté qu’entre 2010 et 2015, les sociétés de capital-risque ont investi plus de 4 milliards de dollars dans des entreprises open source, soit dix fois plus que sur les cinq années précédentes.

Le recours aux fonds de capital-risque pour soutenir les projets open source a été accueilli avec scepticisme par les développeurs (et même par certains acteurs du capital-risque eux-mêmes), du fait de l’absence de modèles économiques ou de revenus prévisibles pour justifier les estimations. Steve Klabnik, un mainteneur du langage Rust, explique le soudain intérêt des capital-risqueurs pour le financement de l’open source :

« Je suis un investisseur en capital-risque. J’ai besoin qu’un grand nombre d’entreprises existent pour gagner de l’argent… J’ai besoin que les coûts soient bas et les profits élevés. Pour cela, il me faut un écosystème de logiciels open source en bonne santé. Donc je fais quoi? … Les investisseurs en capital-risque sont en train de prendre conscience de tout ça, et ils commencent à investir dans les infrastructures. […]
Par bien des aspects, le matériel open source est un produit d’appel, pour que tu deviennes accro…puis tu l’utilises pour tout, même pour ton code propriétaire. C’est une très bonne stratégie commerciale, mais cela place GitHub au centre de ce nouvel univers. Donc pour des raisons similaires, a16z a besoin que GitHub soit génial, pour servir de tremplin à chacun des écosystèmes open source qui existeront à l’avenir… Et a16z a suffisamment d’argent pour en «gaspiller » en finançant un projet sur lequel ils ne récupéreront pas de bénéfices directs, parce qu’ils sont suffisamment intelligents pour investir une partie de leurs fonds dans le développement de l’écosystème. »

GitHub, créé en 2008, est une plateforme de partage/stockage de code, disponible en mode public ou privé, doté d’un environnement ergonomique. Il héberge de nombreux projets open source populaires et, surtout, il est devenu l’épicentre culturel de la croissance explosive de l’open source (dont nous parlerons plus loin dans ce rapport).
GitHub n’a reçu aucun capital-risque avant 2012, quatre ans après sa création. Avant cette date, GitHub était une entreprise rentable. Depuis 2012, GitHub a reçu au total 350 millions de dollars de financements en capital-risque.

Andreessen Horowitz (alias a16z), la firme d’investissement aux 4 millards de dollars qui a fourni l’essentiel du capital de leur première levée de fonds de 100 millions de dollars, a déclaré qu’il s’agissait là de l’investissement le plus important qu’elle ait jamais fait jusqu’alors.
En d’autres termes, la théorie de Steve Klabnik est que les sociétés de capital-risque qui investissent dans les infrastructures open source promeuvent ces plateformes en tant que « produit d’appel », même quand il n’y a pas de modèle économique viable ou de rentabilité à en tirer, parce que cela permet de faire croître l’ensemble de l’écosystème. Plus GitHub a de ressources, plus l’open source est florissant. Plus l’open source est florissant, et mieux se portent les startups. À lui seul, l’intérêt que portent les sociétés d’investissement à l’open source, particulièrement quand on considère l’absence de véritable retour financier, est une preuve du rôle-clé que joue l’open source dans l’écosystème plus large des startups.
Par ailleurs, il est important de noter que la plateforme GitHub en elle-même n’est pas un projet open source, et n’est donc pas un exemple de capital-risque finançant directement l’open source. GitHub est une plateforme à code propriétaire qui héberge des projets open source. C’est un sujet controversé pour certains contributeurs open source.

 

Par des personnes ou un groupe de personnes

Enfin, de nombreux projets d’infrastructures numériques sont intégralement développés et maintenus par des développeurs indépendants ou des communautés de développeurs. Voici quelques exemples :

Python, un langage de programmation, a été développé et publié par un informaticien, Guido van Rossum, en 1991.
Van Rossum déclarait qu’il « était à la recherche d’un projet de programmation « passe-temps », qui [le] tiendrait occupé pendant la semaine de Noël. »
Le projet a décollé, et Python est désormais considéré comme l’un des langages de programmation les plus populaires de nos jours.

Van Rossum reste le principal auteur de Python (aussi connu parmi les développeurs sous le nom de « dictateur bienveillant à vie » et il est actuellement employé par Dropbox, dont les logiciels reposent fortement sur Python.

Python est en partie géré par la Python Software Foundation (NdT: Fondation du logiciel Python), créée en 2001, qui bénéficie de nombreux sponsors commerciaux, parmi lesquel Intel, HP et Google.

RubyGems est un gestionnaire de paquets qui facilite la distribution de programmes et de bibliothèques associés au langage de programmation Ruby.
C’est une pièce essentielle de l’infrastructure pour tout développeur Ruby. Parmi les sites web utilisant Ruby, on peut citer par exemple Hulu, AirBnB et Bloomberg. RubyGems a été créé en 2003 et est géré par une communauté de développeurs. Certains travaux de développement sont financés par Ruby Together, une fondation qui accepte les dons d’entreprises et de particuliers.

Twisted, une bibliothèque Python, fut créée en 2002 par un programmeur nommé Glyph Lefkowitz. Depuis lors,  son usage s’est largement répandu auprès d’individus et d’organisations, parmi lesquelles Lucasfilm et la NASA.
Twisted continue d’être géré par un groupe de volontaires. Le projet est soutenu par des dons corporatifs/commerciaux et individuels ; Lefkowitz en reste l’architecte principal et gagne sa vie en proposant ses services de consultant.

Comme le montrent tous ces exemples, les projets open source peuvent provenir de pratiquement n’importe où. Ce qui est en général considéré comme une bonne chose. Cela signifie que les projets utiles ont le plus de chances de réussir, car ils évitent d’une part les effets de mode futiles inhérents aux startups, et d’autre part la bureaucratie propre aux gouvernements. La nature décentralisée de l’infrastructure numérique renforce également les valeurs de démocratie et d’ouverture d’Internet, qui permet en principe à chacun de créer le prochain super projet, qu’il soit une entreprise ou un individu.
D’un autre côté, un grand nombre de projets utiles proviendront de développeurs indépendants qui se trouveront tout à coup à la tête d’un projet à succès, et qui devront prendre des décisions cruciales pour son avenir. Une étude de 2015 menée par l’Université fédérale de Minas Gerai au Brésil a examiné 133 des projets les plus activement utilisés sur Github, parmi les langages de programmation, et a découvert que 64 % d’entre eux, presque les deux tiers, dépendaient pour leur survie d’un ou deux développeurs seulement.

Bien qu’il puisse y avoir une longue traîne de contributeurs occasionnels ou ponctuels pour de nombreux projets, les responsabilités principales de la gestion du projet ne reposent que sur un très petit nombre d’individus.

Coordonner des communautés internationales de contributeurs aux avis arrêtés, tout en gérant les attentes d’entreprises classées au Fortune 500 qui utilisent votre projet, voilà des tâches qui seraient des défis pour n’importe qui. Il est impressionnant de constater combien de projets ont déjà été accomplis de cette manière. Ces tâches sont particulièrement difficiles dans un contexte où les développeurs manquent de modèles clairement établis, mais aussi de soutien institutionnel pour mener ce travail à bien. Au cours d’interviews menées pour ce rapport, beaucoup de développeurs se sont plaints en privé qu’ils n’avaient aucune idée de qui ils pouvaient solliciter pour avoir de l’aide, et qu’ils préféreraient « juste coder ».

Pourquoi continuent-ils à le faire ? La suite de ce rapport se concentrera sur pourquoi et comment les contributeurs de l’open source maintiennent des projets à grande échelle, et sur les raisons pour lesquelles c’est important pour nous tous.

Dans ce nouveau chapitre de l’ouvrage de Nadia Eghbal Des routes et des ponts que le groupe Framalang vous traduit semaine après semaine (si vous avez raté les épisodes précédents), l’autrice⁽¹⁾ établit cette fois-ci une comparaison éclairante entre l’infrastructure physique dont nous dépendons sans toujours en avoir conscience et l’infrastructure numérique dont la conception et le processus sont bien différents.

Qu’est-ce qu’une infrastructure numérique, et comment est-elle construite ?

Traduction Framalang : Diane, Penguin, Asta, teromene, Julien / Sphinx, Luc, salade, AFS, xi, goofy

Dans un chapitre précédent de ce rapport, nous avons comparé la création d’un logiciel à la construction d’un bâtiment. Ces logiciels publiquement disponibles contribuent à former notre infrastructure numérique. Pour comprendre ce concept, regardons comment les infrastructures physiques fonctionnent.

Tout le monde dépend d’un certain nombre d’infrastructures physiques qui facilitent notre vie quotidienne. Allumer les lumières, aller au travail, faire la vaisselle : nous ne pensons pas souvent à l’endroit d’où viennent notre eau ou notre électricité, mais heureusement que nous pouvons compter sur les infrastructures physiques. Les partenaires publics et privés travaillent de concert pour construire et maintenir nos infrastructures de transport, d’adduction des eaux propres et usées, nos réseaux d’électricité et de communication.

De même, même si nous ne pensons pas souvent aux applications et aux logiciels que nous utilisons quotidiennement, tous utilisent du code libre et public pour fonctionner. Ensemble, dans une société où le numérique occupe une place croissante, ces projets open source forment notre infrastructure numérique. Toutefois, il existe plusieurs différences majeures entre les infrastructures physiques et numériques, qui affectent la manière dont ces dernières sont construites et maintenues. Il existe en particulier des différences de coût, de maintenance, et de gouvernance.

Les infrastructures numériques sont plus rapides et moins chères à construire.

C’est connu, construire des infrastructures matérielles coûte très cher. Les projets sont physiquement de grande envergure et peuvent prendre des mois ou des années à réaliser.

Le gouvernement fédéral des États-Unis a dépensé 96 milliards de dollars en projets d’infrastructure en 2014 et les gouvernements des différents états ont dépensé au total 320 milliards de dollars cette même année. Un peu moins de la moitié de ces dépenses (43 pour cent) a été affectée à de nouvelles constructions ; le reste a été dépensé dans des opérations de maintenance de l’infrastructure existante.

Proposer puis financer des projets de nouvelles infrastructures physiques peut être un processus politique très long. Le financement des infrastructures de transport a été un sujet délicat aux États-Unis d’Amérique au cours de la dernière décennie lorsque le gouvernement fédéral a été confronté à un manque de 16 milliards de dollars pour les financer.

Le Congrès a récemment voté la première loi pluriannuelle de financement des transports depuis 10 ans, affectant 305 milliards de dollars aux autoroutes et autres voies rapides après des années d’oppositions politiques empêchant la budgétisation des infrastructures au-delà de deux années.

Même après qu’un nouveau projet d’infrastructure a été validé et a reçu les fonds nécessaires, il faut souvent des années pour le terminer, à cause des incertitudes et des obstacles imprévus auxquels il faut faire face.

Dans le cas du projet Artère Centrale/Tunnel à Boston, dans le Massachusetts, connu aussi sous le nom de Big Dig, neuf ans se sont écoulés entre la planification et le début des travaux. Son coût prévu était de 2,8 milliards de dollars, et il devait être achevé en 1998. Finalement, le projet a coûté 14,6 milliards de dollars et n’a pas été terminé avant 2007, ce qui en fait le projet d’autoroute le plus cher des États-Unis.

En revanche, les infrastructures numériques ne souffrent pas des coûts associés à la construction des infrastructures physiques comme le zonage ou l’achat de matériels. Il est donc plus facile pour tout le monde de proposer une nouvelle idée et de l’appliquer en un temps très court. MySQL, le second système de gestion de base de données le plus utilisé dans le monde et partie intégrante d’une collection d’outils indispensables qui aidèrent à lancer le premier boum technologique, fut lancé par ses créateurs, Michael Widenius & David Axmark, en mai 1995. Ils mirent moins de deux années à le développer.

Il a fallu à Ruby, un langage de programmation, moins de trois ans entre sa conception initiale en février 1993 et sa publication en décembre 1995. Son auteur, l’informaticien Yukihiro Matsumoto, a décidé de créer le langage après une discussion avec ses collègues.

Les infrastructures numériques se renouvellent fréquemment

Comme l’infrastructure numérique est peu coûteuse à mettre en place, les barrières à l’entrée sont plus basses et les outils de développement changent plus fréquemment.

L’infrastructure physique est construite pour durer, c’est pourquoi ces projets mettent si longtemps à être planifiés, financés et construits. Le métro de Londres, le système de transport en commun rapide de la ville, fut construit en 1863 ; les tunnels creusés à l’époque sont encore utilisés aujourd’hui.

Le pont de Brooklyn, qui relie les arrondissements de Brooklyn et de Manhattan à New York City, fut achevé en 1883 et n’a pas subi de rénovations majeures avant 2010, plus de cent ans plus tard. L’infrastructure numérique nécessite non seulement une maintenance et un entretien fréquents pour être compatible avec d’autres logiciels, mais son utilisation et son adoption changent également fréquemment. Un pont construit au milieu de New York City aura un usage garanti et logique, en proportion de la hausse ou la diminution de la population. Mais un langage de programmation ou un framework peut être extrêmement populaire durant plusieurs années, puis tomber en désuétude lorsque apparaît quelque chose de plus rapide, plus efficace, ou simplement plus à la mode.

Par exemple, le graphique ci-dessous montre l’activité des développeurs de code source selon plusieurs langages différents. Le langage C, l’un des langages les plus fondamentaux et les plus utilisés, a vu sa part de marché diminuer alors que de nouveaux langages apparaissaient. Python et JavaScript, deux langages très populaires en ce moment, ont vu leur utilisation augmenter régulièrement avec le temps. Go, développé en 2007, a connu plus d’activité dans les dernières années.

Tim Hwang, dirigeant du Bay Area Infrastructure Observatory, qui organise des visites de groupe sur des sites d’infrastructures physiques, faisait remarquer la différence dans une interview de 2015 donnée au California Sunday Magazine :

« Beaucoup de membres de notre groupe travaillent dans la technologie, que ce soit sur le web ou sur des logiciels. En conséquence, ils travaillent sur des choses qui ne durent pas longtemps. Leur approche c’est ‘On a juste bidouillé ça, et on l’a mis en ligne’ ou : ‘On l’a simplement publié, on peut travailler sur les bogues plus tard’. Beaucoup d’infrastructures sont construites pour durer 100 ans. On ne peut pas se permettre d’avoir des bogues. Si on en a, le bâtiment s’écroule. On ne peut pas l’itérer. C’est une façon de concevoir qui échappe à l’expérience quotidienne de nos membres. »

Cependant, comme l’infrastructure numérique change très fréquemment, les projets plus anciens ont plus de mal à trouver des contributeurs, parce que beaucoup de développeurs préfèrent travailler sur des projets plus récents et plus excitants. Ce phénomène est parfois référencé comme le « syndrome de la pie » chez les développeurs, ces derniers étant attirés par les choses « nouvelles et brillantes », et non par les technologies qui fonctionnent le mieux pour eux et pour leurs utilisateurs.

Les infrastructures numériques n’ont pas besoin d’autorité organisatrice pour déterminer ce qui doit être construit ou utilisé

En définitive, la différence la plus flagrante entre une infrastructure physique et une infrastructure numérique, et c’est aussi un des défis majeurs pour sa durabilité, c’est qu’il n’existe aucune instance décisionnelle pour déterminer ce qui doit être créé et utilisé dans l’infrastructure numérique. Les transports, les réseaux d’adduction des eaux propres et usées sont généralement gérés et possédés par des collectivités, qu’elles soient fédérales, régionales ou locales. Les réseaux électriques et de communication sont plutôt gérés par des entreprises privées. Dans les deux cas, les infrastructures sont créées avec une participation croisée des acteurs publics et privés, que ce soit par le budget fédéral, par les entreprises privées ou les contributions payées par les usagers.

Dans un État stable et développé, nous nous demandons rarement comment une route est construite ou un bâtiment électrifié. Même pour des projets financés ou propriétés du privé, le gouvernement fédéral a un intérêt direct à ce que les infrastructures physiques soient construites et maintenues.

De leur côté, les projets d’infrastructures numériques sont conçus et construits en partant du bas. Cela ressemble à un groupe de citoyens qui se rassemblent et décident de construire un pont ou de créer leur propre système de recyclage des eaux usées. Il n’y a pas d’organe officiel de contrôle auquel il faut demander l’autorisation pour créer une nouvelle infrastructure numérique.

Internet lui-même possède deux organes de contrôle qui aident à définir des standards : l’IETF (Internet Engineering Task Force) et le W3C (World Wide Web Consortium). L’IETF aide à développer et définit des standards recommandés sur la façon dont les informations sont transmises sur Internet. Par exemple, ils sont la raison pour laquelle les URL commencent par “HTTP”. Ils sont aussi la raison pour laquelle nous avons des adresses IP – des identifiants uniques assignés à votre ordinateur lorsqu’il se connecte à un réseau. À l’origine, en 1986, il s’agissait d’un groupe de travail au sein du gouvernement des USA mais l’IETF est devenue une organisation internationale indépendante en 1993.

L’IETF elle-même fonctionne grâce à des bénévoles et il n’y a pas d’exigences pour adhérer : n’importe qui peut joindre l’organisation en se désignant comme membre. Le W3C (World Wide Web Consortium) aide à créer des standards pour le World Wide Web. Ce consortium a été fondé en 1994 par Tim Berners-Lee. Le W3C a tendance à se concentrer exclusivement sur les pages web et les documents (il est, par exemple, à l’origine de l’utilisation du HTML pour le formatage basique des pages web). Il maintient les standards autour du langage de balisage HTML et du langage de formatage de feuilles de style CSS, deux des composants de base de n’importe quelle page web. L’adhésion au W3C, légèrement plus formalisée, nécessite une inscription payante. Ses membres vont des entreprises aux étudiants en passant par des particuliers.

L’IETF et le W3C aident à gérer les standards utilisés par les pièces les plus fondamentales d’Internet, mais la couche du dessus – les choix concernant le langage utilisé pour créer le logiciel, quels frameworks utiliser pour les créer, ainsi que les bibliothèques à utiliser – sont entièrement auto-gérés dans le domaine public (bien entendu, de nombreux projets de logiciels propriétaires, particulièrement ceux qui sont régis par de très nombreuses normes, tels que l’aéronautique ou la santé peuvent avoir des exigences concernant les outils utilisés. Ils peuvent même développer des outils propriétaires pour leur propre utilisation).

Avec les infrastructures physiques, si le gouvernement construit un nouveau pont entre San Francisco et Oakland, ce pont sera certainement utilisé. De la même façon, lorsque le W3C décide d’un nouveau standard, tel qu’une nouvelle version de HTML, il est formellement publié et annoncé. Par exemple, en 2014, le W3C a annoncé HTML 5, la première révision majeure de HTML depuis 1997, qui a été développé pendant sept ans.

En revanche, lorsqu’un informaticien souhaite créer un nouveau langage de programmation, il ou elle est libre de le publier et ce langage peut ou peut ne pas être adopté. La barre d’adoption est encore plus basse pour les frameworks et bibliothèques : parce qu’ils sont plus faciles à créer, et plus facile pour un utilisateur à apprendre et implémenter, ces outils sont itérés plus fréquemment.

Mais le plus important c’est que personne ne force ni même n’encourage fortement quiconque à utiliser ces projets. Certains projets restent plus théoriques que pratiques, d’autres sont totalement ignorés. Il est difficile de prédire ce qui sera véritablement utilisé avant que les gens ne commencent à l’utiliser.

Les développeurs aiment se servir de l’utilité comme indicateur de l’adoption ou non d’un projet. Les nouveaux projets doivent améliorer un projet existant, ou résoudre un problème chronique pour être considérés comme utiles et dignes d’être adoptés. Si vous demandez aux développeurs pourquoi leur projet est devenu si populaire, beaucoup hausseront les épaules et répondront : « C’était la meilleure chose disponible ». Contrairement aux startups technologiques, les nouveaux projets d’infrastructure numérique reposent sur les effets de réseau pour être adoptés par le plus grand nombre.

L’existence d’un groupe noyau de développeurs motivés par le projet, ou d’une entreprise de logiciels qui l’utilise, contribue à la diffusion du projet. Un nom facilement mémorisable, une bonne promotion, ou un beau site Internet peuvent ajouter au facteur « nouveauté » du projet. La réputation d’un développeur dans sa communauté est aussi un facteur déterminant dans la diffusion d’un projet.

Mais en fin de compte, une nouvelle infrastructure numérique peut venir d’à peu près n’importe où, ce qui veut dire que chaque projet est géré et maintenu d’une façon qui lui est propre.

 

(1) pourquoi « autrice » ? Il semble que ce mot soit légitime au regard de l’histoire de la langue. Voyez aussi une étude plus complète.

Vous l’avez sans doute vu passer à plusieurs reprises : notre dessinateur Gee nous a concocté cette année un petit GIF animé (avec variantes) pour illustrer les sorties de nos différents services et a même poussé le concept jusqu’à en faire une vidéo avec musique et effets sonores !

Ce dessin animé est sous licence CC-By-Sa. Et comme chez Framasoft, on est un peu monomaniaques, il l’a bien sûr été réalisé uniquement avec des outils libres ! Ce petit making-of, que vous pouvez également retrouver sur le site de Gee, vous explique les différentes étapes pour réaliser cette courte animation.

Les outils

Bon. Quand Pouhiou m’a envoyé un mail pour me demander s’il y avait moyen de faire un petit GIF avec le scénario qu’il avait écrit (avec une date limite assez serrée), je me suis penché sur les logiciels d’animation libre. J’ai tout d’abord essayé Synfig qui semblait être le plus plébiscité. J’ai importé un personnage bricolé dans Inkscape, j’ai essayé de l’animer en fouillant un peu les menus et en regardant des tutos sur Internet. Sans succès (je dois pas être doué). J’ai laissé tomber quand le logiciel m’a planté entre les mains après avoir cliqué sur un bouton au hasard. J’ai vaguement jeté un œil du côté de Pencil2d, mais ça ne m’avait pas l’air beaucoup plus simple.

Qu’à cela ne tienne. Quand on est un peu pressé, mieux vaut s’en tenir à des logiciels qu’on connaît, même s’ils ne sont pas exactement faits pour la tâche qu’on a à accomplir. En l’occurrence, je me suis contenté d’utiliser :

• Mon chouchou Inkscape pour faire les dessins, on ne change pas une équipe qui gagne (et il est aussi utilisable en ligne de commande, un très gros atout !)
• ImageMagick pour générer le GIF
• Un peu de Ruby pour automatiser un peu le processus

Je préviens d’avance que j’ai procédé volontairement de manière quick’n’dirty. Il est évident que tout ce que j’ai fait peut-être réalisé plus efficacement et proprement si on maîtrise un parser XML, les expressions régulières, etc. etc.

Animons… à l’ancienne !

Puisque je n’utilise aucun outil qui facilite l’animation (pour calculer automatiquement des images entre deux positions-clefs, par exemple) je fais au plus simple : décomposer le mouvement image par image et dessiner chaque image séparément. J’assume du coup le côté « saccadé » car je n’avais franchement pas le courage de faire du 25 images par seconde 🙂

Pour la marche du manchot, une boucle de 8 images :

Pour animer l’uppercut, je me suis inspiré des sprites d’un certain jeu de baston assez connu…

Et pour la partie jardinage, j’ai fait à l’instinct avec une boucle de deux images quand le manchot grattouille la terre.

Reste le soldat qui est beaucoup moins animé mais possède son petit nombre d’images quand même. Je dessine le bouclier vide, sachant que le logo sur le bouclier va varier selon les projets.

Voilà ! Les autres éléments sont fixes (ou pratiquement) :

Et enfin, un fond qui est raccordable à gauche et à droite pour pouvoir boucler facilement.

On assemble…

C’est là où ça devient carrément artisanal (et où, encore une fois, il y a moyen de faire plus simple – et moins gourmand en espace ! – si on sait scripter du SVG comme un chef). Je fais un calque (toujours sur Inkscape) par image, en dupliquant les éléments qui doivent l’être à chaque fois. Du coup le fichier source devient vite très gros…

On commence par 2 cycles de marche (soit 16 images). C’est le fond qui bouge. J’ai calculé qu’à la fin des deux cycles, mon personnage devait avoir parcouru à peu près les 2 tiers du décors qui fait 860 pixels de large. On doit donc parcourir (2/3)*860=537,33 pixels en 16 frames. À chaque calque, je duplique le précédent et je sélectionne mon fond : Objet/Transformer/Déplacement horizontal de -35,84 pixels.

Arrivé à la dernière des 16 frames, le nuage doit être dans sa position finale. Je le mets, puis je fais l’opération inverse (copie du nuage sur les calques précédents et mouvement de 35,84 pixels jusqu’à ce qu’il sorte du cadre). Avec toutes ces copies, le fichier fait déjà 11Mio ! Je décide de diviser l’animation en plusieurs fichiers pour ne pas exploser la mémoire de ce pauvre Inkscape…

Le deuxième fichier SVG commence aux éclairs et termine quand le soldat est éjecté de l’écran. Pas grand-chose à dire, pas de formule mathématique ici, j’ai animé en essayant/regardant/corrigeant jusqu’à arriver à un enchaînement qui me semblait bien. Mine de rien, le deuxième fichier fait déjà 20Mio… On passe au troisième fichier !

On commence par recentrer la « caméra » sur notre personnage : rien de bien compliqué, toute l’image bouge en même temps. On en profite pour lancer l’animation du manchot qui grattouille la terre. Rien de bien compliqué pour faire apparaître l’arbre dans une explosion de lumière 🙂

Mais c’est là que les choses se corsent : il faut que je termine en bouclant sur le début, il faut donc que la dernière image se raccorde avec la première. J’ai déjà prévu un fond raccordable, par contre mon personnage a un peu bougé à l’arrache avec le combat et le plantage d’arbre. Et en plus, horreur et damnation, je me rends compte que mon bel arbre dépasse sur la partie de l’image qui apparaît sur la première image !

Aaaargh ! Trois solutions :

• Tout refaire pour placer l’éclair, l’arbre et cie. plus à gauche (non mais ça va pas la tête ?!)
• Recoller le morceau d’arbre sur les premières images pour rester cohérent (mais du coup ce serait bizarre de le voir dès le début)
• Utiliser un habile trucage 🙂

Et c’est la dernière solution (la plus feignasse, j’assume) que j’ai choisie. Et je suis assez content parce que cette petite « triche » ne se voit pratiquement pas (sauf si on le sait). Vous l’avez vue ? Eh bien c’est simple : l’arbre bouge plus vite que le fond sur les dernières images ! De telle sorte qu’il semble naturel qu’il soit sorti de l’image quand on revient sur la première image…

Bon, n’empêche que c’est quand même un peu le bazar, puisque tout doit un peu bouger pour retourner à la position initiale :

• Par rapport au fond, le manchot doit avancer de 327 pixels
• Pour retrouver sa position initiale (sur le bord gauche de l’image), le manchot doit reculer de 80 pixel
• Le fond doit reculer de 400 pixels
• L’arbre doit reculer de 585 pixels

Puisque par rapport au fond, le manchot doit avancer de 327 pixels, on peut calculer le nombre de « pas » qu’il doit faire (= le nombre d’images dans la boucle de marche). On se rappelle que manchot faisait 35,84 pixels par pas au début. Pour parcourir 327 pixels, il lui faut donc 9,12 pas (arrondis à 9). Maintenant qu’on connaît le nombre d’images nécessaires et les déplacements à faire, il n’y a plus qu’à enchaîner ! Pendant 9 images :

• Le manchot bouge de 8,89 pixels
• Le fond bouge de 44,44 pixels
• L’arbre bouge de 65 pixels (sans le problème décrit plus haut, il aurait dû bouger à la même vitesse que le fond, ici il est 46% plus rapide !)

Et voilà ! Nous avons maintenant toutes nos images, y’a plus qu’à assembler !

Scriptons

On est quand même à 3 fichiers SVG qui totalisent 50Mio et 81 calques. Hors de question de se taper les exportations à la main (surtout que je veux pouvoir facilement tester et changer des choses). Du coup, c’est l’heure de scripter. J’ai choisi le Ruby pour plusieurs raisons :

• Déjà, parce que c’est ce que j’utilise en général quand je dois scripter (du coup je maîtrise mieux — mais pas tant que ça vu que je ne scripte pas si souvent)
• C’est un langage relativement dégueulasse (on peut écrire à peu près n’importe quoi) mais qui du coup est simple à faire fonctionner
• C’est rigolo comme langage 🙂

Tout d’abord, comme je l’ai dit en introduction, il faut savoir qu’Inkscape a un mode ligne de commande, et c’est super ! On peut choisir d’exporter un fichier en PNG avec la taille que l’on veut et en sélectionner un objet de la scène. Et ça tombe bien, puisque mes calques sont des objets et qu’en sélectionnant chaque calque un par un dans l’ordre des numéros, on obtient toutes les images de l’animation dans le bon ordre.

Et là, il y a un hic : pour choisir un objet, Inkscape veut qu’on lui donne son ID. Sauf que son ID n’a rien à voir avec le Nom qu’on lui a donné dans Inkscape. Nom que j’avais pris soin d’écrire imgXXX (avec XXX le numéro de l’image). Groumpf. Qu’à cela ne tienne, en faisant un petit grep, on se rend vite compte que les attributs id et name d’un calque sont juste à côté. On commence donc par récupérer l’ID correspondant à chaque calque avec un petit hack un peu crade mais qui marche :

Ensuite, une fois qu’on a récupéré les bons ID associés aux bons noms, on peut lancer l’exportation des calques vers des PNG avec une bête boucle et un appel à Inkscape :

Il ne reste plus qu’à compiler le GIF à l’aide d’ImageMagick. La façon la plus simple de faire est celle-ci :

Mais dans mon cas, je souhaite que certaines frames soient plus longues que d’autres (par exemple, celles où le soldat parle). Dans ce cas-là, j’écris la commande ImageMagick frame par frame en précisant la durée à chaque fois (notez qu’on pourrait ne préciser la durée par défaut qu’après chaque frame qui ne l’utilise pas, mais bon, c’est le script qui s’en charge alors peu importe). J’ai oublié de le copier/coller, mais la variable delay est égale à 10 bien sûr.

ET VOILÀ !

Notre GIF est tout prêt, tout beau. Ensuite, il y a encore moyen de réduire le poids du GIF en réduisant la qualité etc. J’ai aussi généré pas mal de variantes avec des changements de couleur (via des scripts aussi), mais je vous passe les détails. J’arrête là pour le making-of, car si je commence à vous parler de la vidéo (et du son), on n’est pas rendus 🙂

Vous pouvez télécharger le script complet (et éventuellement les sources, mais même compressé, c’est gros !). Tout est libre, toujours sous licence CC-By-Sa.

Faites tourner ! Et bon dimanche 😉