L’éradication invisible de Flash

Mercredi 10 février

Vous non plus, vous n’avez pas remarqué quand votre navigateur a définitivement cessé de supporter Flash ?

Mais si, Flash. Vous savez, ce plugin qui permettait d’afficher des publicités et de vous suivre à la trace même quand vous supprimiez les cookies. Qui permettait de faire des sites bling bling donnant la nausée, complètement inaccessibles et impossibles à mettre en marque-page. Ce plugin qui faisait surchauffer votre ordinateur.

Ceci dit, Flash fut aussi utilisé, plus loin dans le passé, pour concevoir toutes sortes de vidéos d’animation et de petits jeux vidéo parfois très créatifs. Et, au début des années 2000, dans un monde où YouTube™ n’existait pas, il fut l’outil de choix pour bien des créations qui marquèrent leur époque.

Certains discours mythifiants attribuent la déchéance de Flash à la volonté divine de Steve Jobs qui, ne recherchant que les plus pures et les plus nobles des technologies pour son messianique téléphone multifonctions, aurait chassé le plugin d’Adobe du jardin d’iPhone OS® à cause de son inefficacité technique blasphématoire.

La réalité est un peu plus nuancée que cela.

Le non-support de Flash sur les iPhone a probablement été un peu gênant, mais davantage pour des raisons marketing que strictement techniques. Quand, en 2010, Jobs mettait en scène une colère contre Flash, cela faisait déjà un moment qu’Adobe poussait à l’utilisation d’AIR (que l’on va qualifier, pour faire simple, d’intermédiaire entre une machine virtuelle Java et un framework comme Electron). AIR qui, depuis, a été refourgué à une filiale de Samsung.

Flash et moi, on n’a jamais été vraiment copains

Quand j’étais étudiant, on a tenté de me faire commettre des choses en Flash. J’en ai fait très peu, et bien moins que le minimum requis. Cela s’est fait en partie par opportunisme à l’occasion d’une période de congés maladie qui tombait précisément à un moment où je devais réaliser l’un de mes deux plus gros projets Flash. Un projet jamais réalisé, pour lequel je me suis donc pris un beau zéro. L’autre gros projet, un truc de fin d’année à faire pour un autre cours, a été torché et rendu dans un état très incomplet car, globalement, le sens de la pédagogie du professeur concerné était quelque peu en décalage par rapport aux besoins qu’avaient ses étudiants.

Mais, au-delà des ces facteurs externes, la technologie en elle-même me posait déjà problème. Intuition précoce ? Dans nos discussions avec mes camarades, je me sentais bien seul à prendre la défense des technologies ouvertes, non-propriétaires, car j’avais le sentiment que c’était la voie à suivre, quand bien même on trouvait, en face, des choses très woaw et bling bling, futuristes. JavaScript, ce langage standardisé, était vu comme un gadget absolument inutile au sein des navigateurs, et seule sa forme « évoluée », ActionScript, semblait digne de respect.

Je me rappelle avoir ressenti mon refus de terminer mes projets Flash comme une position de principe. Une assertivité qui, en y repensant par la suite, m’a un peu étonné de la part d’un étudiant qui, bien qu’il lisait des choses comme formats-ouverts.org, Openweb ou encore le Standblog (Tristan Nitot n’étant, à cette époque-là, pas encore devenu un gros con), n’en était pas moins tout jeune dans le domaine, et encore en plein apprentissage.

Flash est mort, so what?

L’élimination finale de Flash a beau avoir été planifiée depuis plusieurs années, on pourrait quand même trouver étonnant que celle-ci soit passée complètement inaperçue, non ? Et, surtout, que tout le monde s’en fiche ? N’est-ce pas intéressant ?

Oui et non.

Ça fait plus d’une décennie — autrement dit une éternité selon la cadence inhumaine des évolutions technologiques — que les développeurs ont commencé à se détourner de Flash et, après avoir quelques temps essayé de ménager la chèvre et le chou (car de nombreuses entreprises avaient misé beaucoup d’argent sur Flash et les systèmes associés), même Adobe a fini par le délaisser, au profit d’autres technologies propriétaires. On aurait très bien pu éradiquer les restes de Flash il y a trois ans, ça n’aurait probablement pas fait la moindre différence notable.

La technologie Flash a disparu mais les usages qui en étaient fait ont migré sur des formats ouverts. Aujourd’hui, on recourt à des brouettes entières de JavaScript, mais aussi parfois à des animations et transitions CSS, à du SVG, <canvas>, à des éléments <audio>, etc. L’élément <video> offre depuis des années un potentiel technique prodigieux, de par sa capacité d’interaction avec CSS et tout le reste du DOM (contrairement aux objets Flash, qui étaient isolés dans leur propre boîte noire hermétique au sein d’une page web hôte), mais YouTube et ses concurrents ont quasiment tué ce potentiel, en créant la norme des vidéos hébergées chez eux, de manière centralisée, et incluses via des <iframe>, reproduisant ainsi à l’identique la rigidité inflexible des .swf de Flash à l’époque.

Une victoire des formats ouverts ?

Les usages n’ont pas changé et, de façon logique, ils ont progressé en accompagnant la fuite en avant générale et indécente du Web vers une consommation — on devrait plutôt dire « gaspillage » — toujours plus énorme de ressources et d’énergie.

L’accessibilité, qui était un mirage avec Flash, n’en déplaise au marketing d’Adobe de l’époque, n’y a pas vraiment gagné au change non plus, et ce n’est pas en saupoudrant des attributs aria-machin un peu partout que l’on crée un contenu accessible (c’est seulement un moyen, semble-t-il, de se donner bonne conscience et d’évacuer la question).

Faire du caca avec des formats ouverts plutôt qu’avec des technologies propriétaires, est-ce une véritable amélioration ? J’imagine que c’est « moins pire », mais cette focalisation sur la nature ouverte/fermée, qui a son importance, empêche de prendre du recul sur ce qui, au final, est fait avec ces technologies.

Des formats ouverts, vraiment ?

Par ailleurs, il me semble bon de rappeler qu’un certain nombre de recommandations officielles du W3C, que l’on considère aujourd’hui comme bien bio et nourries au bon grain, ont pour origines des chevaux de Troie issus de multinationales ayant utilisé cet organisme de standardisation comme un moyen de faire du blanchiment technologique.

Ainsi, par exemple, les transitions CSS, les transformations CSS et les animations CSS sont toutes trois issues d’Apple, qui a implémenté unilatéralement ces trucs dans WebKit. Ce qui a été considéré comme une posture très peu sympathique à l’époque, car rappelant les heures sombres de la guerre des navigateurs. Apple a ensuite joué aux faux magnanimes, « proposant » au W3C d’accueillir des spécifications pour mettre ces technologies à disposition du plus grand nombre.

Les dégradés CSS viennent aussi d’Apple, qui a implémenté une syntaxe directement pompée sur SVG. Syntaxe qui connaîtra au moins trois versions majeures avant d’être standardisée pour de bon, ce qui aura créé de véritables cauchemars en terme de compatibilité et d’interopérabilité pendant plusieurs années.

Plus bourrin encore, l’élément <canvas>, une boîte noire très éloignée du fonctionnement habituel des technologies Web classiques, a aussi été forcé par Apple.

Microsoft appliqua des méthodes de blanchiment technologique similaires quelques années plus tard, après avoir tardivement changé sa stratégie générale face aux standards du Web (en passant d’une opposition féroce à une tactique de noyautage, pour tenter indirectement de lutter contre Google — c’est compliqué).

Par ailleurs, on ne peut pas aborder ce sujet sans mentionner le scandale de l’inclusion des DRM dans HTML. Une inclusion défendue par Tim Berners-Lee lui-même, un épisode que l’on retiendra probablement comme la plus grosse connerie de sa carrière, surtout en repensant à la posture fataliste et aux « arguments » proprement stupides utilisés pour justifier sa position.

La politique derrière la technique

Soyons clairs : il ne s’agit pas de dire que les transitions CSS ou que quoi que ce soit seraient forcément pourries car provenant de blanchiment technologique. Il est ici question de dénoncer le procédé, qui est malhonnête et qui force la main aux organismes de standardisation.

Une parenthèse : les contributions d’individus aux standards

Je ne vais pas faire semblant de croire au mythe méritocratique de « chaque développeur est libre de proposer des choses au W3C / WHATWG / etc. » et dénoncer le fait que les multinationales, en amenant leurs propres technologies « clés sur porte », faussent cette saine concurrence.

Il est exact que les personnes au sein des organismes de standardisation sont réellement demandeuses de feedbacks de la part des développeurs (j’ai eu l’occasion d’en discuter à plusieurs reprises lors de View Source et Fronteers en 2019, et c’était vraiment riche d’enseignements).

Et il est également exact que des gens « ordinaires » du métier peuvent contribuer de manière importante (Rachel Andrew, au sujet des CSS Grids, est probablement le meilleur exemple). Mais ça demande des efforts absolument énormes, et sur du (très) long terme. Il faut aussi se plier aux logiques de fonctionnement internes desdits organismes. C’est presque un boulot à temps plein.

C’est pourquoi je n’adhère pas aux discours de forums démocratiques et bisounours. Ces organismes ont leurs propres contradictions et, ils ont beau souhaiter des feedbacks en provenance du terrain, il me semble percevoir que, comme la plupart des institutions qui bossent sur leurs propres trucs à l’écart du monde, ils préfèrent quand même nettement quand ces feedbacks corroborent leurs a priori et leurs hypothèses de travail plutôt que de se voir signifier qu’ils font fausse route. Faut-il rappeler le mélange d’arrogance et de condescendance dont avait fait preuve le W3C quand à peu près tout le monde leur disait que le XHTML 2.0 tel qu’envisagé était vraiment une très mauvaise idée ? Une arrogance académique aux conséquences majeures : elle mena à une sécession, à la création du WHATWG, et à de profonds changements de direction dans l’évolution des standards du Web les plus fondamentaux, dont HTML lui-même.

Fin de la parenthèse.

Apple et le détournement de HTML5

Pour en revenir au sujet des standards et des pratiques malhonnêtes visant à en construire certains par de faux consensus autour de technologies conçues et planifiées en dehors des organismes de standardisation, on touche là à des questions centrales. Dont celle de l’intérêt, pour une entreprise, que tout le secteur utilise sa manière de penser, de concevoir. Son vocabulaire. Sa vision des choses.

Vous vous rappelez des promesses de Steve Jobs qui, lors du lancement de l’iPhone, prétendait que les développeurs Web pourraient créer des applications iPhone OS (renommé ensuite en iOS) en utilisant HTML5 ? En créant leurs propres ajouts — <canvas>, transformations CSS, etc. — par-dessus les standards existants, Apple tentait de détourner les technologies à la base du Web pour servir ses propres intérêts stratégiques. Le but était de réutiliser HTML, CSS et JavaScript pour les rendre capable de réaliser des applications. Les développeurs Web étaient infiniment plus nombreux que les développeurs Objective-C et donc, pour une entreprise qui avait besoin de créer un catalogue d’applications depuis zéro, ça avait tout son sens de tenter d’attirer les professionnels maîtrisant les technologies Web.

The full Safari engine is inside of iPhone. And so, you can write amazing Web 2.0 and Ajax apps that look exactly and behave exactly like apps on the iPhone. And these apps can integrate perfectly with iPhone services. They can make a call, they can send an email, they can look up a location on Google Maps.

And guess what? There’s no SDK that you need! You’ve got everything you need if you know how to write apps using the most modern web standards to write amazing apps for the iPhone today. So developers, we think we’ve got a very sweet story for you. You can begin building your iPhone apps today.

L’un des avantages de ce système — pour Apple et ses pulsions de contrôle — était aussi que les applications ainsi créées restaient bien gentiment contenues dans Safari. L’idée était certes d’exposer des fonctionnalités hardware (téléphone, SMS, etc.) mais sans devoir donner un accès « bas niveau » direct au système d’exploitation.

Cependant, le premier iPhone a été annoncé, logiquement, à la WWDC, donc devant une salle remplie de développeurs Mac OS X. Des gens qui font de l’Objective-C à longueur de journée. Ils n’ont pas trop apprécié.

Ainsi, après une brutale volte-face, Apple finira par sortir l’App Store, un environnement centralisé, complètement contrôlé, propriétaire, qui rendra finalement Steve Jobs heureux tout en satisfaisant les développeurs Mac traditionnels.

Firefox OS

Ironiquement, quelques années plus tard, avec Firefox OS, Mozilla concrétisera pour de vrai les promesses de Steve Jobs : pouvoir développer des applications natives uniquement à base de technologies Web, et pouvant accéder aux différentes fonctionnalités matérielles d’un smartphone. Avec une grosse différence, cependant : plutôt que de faire tourner ces applications dans le navigateur Firefox (qui serait lui-même installé sur un système d’exploitation), c’était l’intégralité de l’OS qui était écrit en HTML, CSS et JavaScript, et rendu via Firefox (ou plus précisément Gecko, son moteur de rendu). Ainsi, chaque application disposait de son icône à l’écran, etc.

Je me rappelle avoir vu, à l’époque, des applications pour réaliser un export, sur un carte SD, de tous ses SMS en utilisant à peine une vingtaine lignes de code JavaScript. Au-delà du côté prodigieusement concis et efficace de la chose, l’une des promesses de Firefox OS était de contribuer à briser les murs propriétaires qui rendent les applications mobiles strictement incompatibles entre systèmes d’exploitation (et obligent donc, aujourd’hui encore, à faire deux, trois ou quatre fois le même travail depuis zéro pour reconstruire chaque application pour les différents systèmes). Bref, apporter aux applications mobiles ce que le Web avait permis pour les ordinateurs.

Mais, on s’en doute, pour permettre à du code JavaScript de téléphoner ou de contrôler un vibreur, il fallait créer de nouvelles API. Et les ajouter aux standards existants. Mozilla avait donc écrit des spécifications dédiées, ensuite soumises au W3C.

Du coup, Apple et Mozilla, tous des salauds, tous au bûcher ?

Non. Si l’on se repose la question de la finalité politique, on doit reconnaître à Mozilla d’avoir été dans une véritable optique de proposition, et non d’unilatéralisme à la Apple (façon « je me fous de ce que vous décidez, moi j’implémente quand même, et j’utiliserai mes parts de marché pour rallier les développeurs à ma vision des choses »). En même temps, Mozilla n’avait aucun téléphone messianique à vendre, ils n’auraient donc de toute façon pas pu jouer les gros bras.

Par ailleurs, Mozilla a beau faire beaucoup de merde ces dernières années, ils continuent d’aller, par leur nature même, vers une certaine conception de l’intérêt général, là où les GAFAM ne cherchent qu’à servir leurs intérêts privés. Pour le dire autrement, malgré toutes leurs conneries, ils restent moins pires que tous les autres.

Firefox OS, pauvre petit ange parti trop tôt, a été sauvagement assassiné par infanticide. Il m’a fallu quelques années de patience et deux bonnes heures et demie de discussions mouvementées avec Pascal Chevrel lors d’une édition du FOSDEM pour enfin connaître les bonnes raisons qu’avait Mozilla d’occire sa propre création — jusque là, j’avais surtout une liste longue comme le bras de mauvaises raisons. Ça reste néanmoins une perte et un gâchis considérables.

Flash est mort, mais rien n’a fondamentalement changé

On l’a dit, les usages de technologies ouvertes ayant remplacé les cochonneries en Flash/ActionScript font autant de tort que les boîtes noires propriétaires qu’étaient les .swf compilés. Comme (presque) toujours, le problème n’est pas tellement dans les technologies en elles-mêmes mais dans ce qui en est fait.

Par ailleurs, les tentatives de boîtes privées de coloniser le Web avec leurs propres approches technologiques sont toujours bien présentes, mais sont devenues plus vicieuses.

Avant Macromedia/Adobe, les coupables étaient Netscape et Microsoft, durant la guerre des navigateurs, chacun implémentant des choses volontairement incompatibles avec le navigateur du concurrent. Par la suite, après Flash, ce sont Apple, Microsoft, Google, Facebook, la MPAA (pour les DRM dans HTML) et d’autres encore qui se sont mis à faire du blanchiment technologique et/ou du lobbying intensif. Le contrôle des normes, des standards, est un enjeu gigantesque pour ceux qui servent des intérêts privés.

Dans une certaine mesure, on peut même considérer que le WHATWG lui-même est partiellement coupable, bien que sa situation soit particulière. La présence en son sein de trois des GAFAM fait que ses travaux — qui visent une certaine conception de l’intérêt général — sont forcément traversés par des conflits d’intérêts.

Rien n’a fondamentalement changé, et c’est notamment pour ça que tout le monde se fiche de la disparition finale de Flash. Côté vidéos, YouTube (donc Google) a pris le pouvoir. Côté conception de sites, toutes sortes de logiciels (y compris venant de chez Adobe) permettent aujourd’hui de pondre du bling bling énergivore, inaccessible et donnant la nausée.

Mémoire

Indépendamment de la question des usages, passés et actuels, reste la question de l’archivage et de la sauvegarde des innombrables réalisations en Flash que l’on peut encore trouver sur le Web, y compris sur des sites qui ne seront plus jamais mis à jour. Comme je le disais au début de ce texte, Flash a été le vecteur de nombreuses créations culturelles, de memes et, globalement, d’un ensemble de communs.

Un certain nombre de films d’animations ont été convertis en vidéos et hébergés sur YouTube (pour le fun, citons par exemple le titanesque Super Mario Bros. Z, qui a même sa propre page Wikipedia).

L’Internet Archive est venue à la rescousse et a déjà sauvegardé quelques milliers de trucs (dont l’indispensable Badger, qui avait lui-même donné naissance à d’autres memes à sa suite). Quant à la lecture de ces contenus dans un monde désormais sans Flash Player®, ils utilisent Ruffle, un émulateur Flash écrit en Rust. Qui s’exécute dans le navigateur via WebAssembly (c’est overkill. Dans un sens, c’est approprié. Ça rappelle l’inefficacité du lecteur Flash officiel).

Et voilà

Flash n’est plus, et le Web, depuis longtemps préparé à cette disparition, n’a pas poussé le moindre hoquet pour l’occasion.

Quelques morceaux sont conservés, pour reprendre les mots de l’Internet Archive, « dans des petites boîtes, comme dans un musée », tels des ossements de dinosaures.

Des développeurs continuent à faire n’importe quoi et, ça, c’est inévitable quel que soit la technologie utilisée.

Et moi, j’ai encore écrit une longue tartine qui part dans tous les sens.