Pour l'écologie, mettons HTTP 1 à la poubelle ?

Avant d'aller dans le dur du sujet, commençons par la base. Qu'est-ce que HTTP ? Une quasi-non-réponse pourrait être d'indiquer de quoi c'est l'acronyme : HyperText Transfer Protocol. Mais on convient que ça n'aidera pas beaucoup le néophyte, si tant est que ça ne contribue pas à l'assommer, en rajoutant du non-compris. Énonçons donc les choses simplement : c'est un protocole ordinatique de communication. Cela en est un parmi bien d'autres, donc ça n'est pas une définition suffisamment différentiente, quoi que ça aide déjà à se faire une idée. Évoquons alors l'usage : c'est le protocole du Web.

Pour comprendre maintenant un peu mieux ce que c'est, condition nécessaire à la compréhension des enjeux écologiques liés, il faut se demander comment on intéragit avec le Web. D'abord, il faut cerner par quel moyen logiciel, ou plus exactement par quel type de logiciel. C'est simple : on parcourt le Web avec un navigateur web. Et qu'est-ce que ça affiche ? Encore une fois, les webonautes le savent bien à priori : des pages web. Mais qu'est-ce qu'une page web ?

On peut répondre sans répondre : une page web est ce qu'affiche un navigateur web. Ça n'aide évidemment pas. Très abstraitement, mais véridiquement, c'est un document ordinatique. Mais n'importe qui ayant utilisé un logiciel de bureautique sait que la page web n'est pas l'unique type de document. Qu'est-ce qui différencie alors une page web de disons un document texte "classique" (par exemple au format PDF ou ODT) ? En simple utilisateur/utilisatrice, on n'est pas censé s'en rendre compte, mais c'est que du point de vue utilisateur/utilisatrice une page web peut être composé de plusieurs documents et du point de vue technique qu'une page web peut demander l'inclusion d'un ou plusieurs autres documents. Les ordinatistes (manière épicène pour ordinaticiens et ordinaticiennes) pourraient avoir à y redire, mais c'est là suffisant pour le sujet de cet article.

Toutefois on peut ne pas bien voir, ou pas du tout, ce que peut être ces éventuels documents qui font la page web tel qu'affiché par le navigateur web. Il y a d'abord l'élément nécessaire, la page web d'un point de vue technique, c'est-à-dire plus précisément le page HTML (HyperText Markup Language). Ensuite, le plus courant, et le plus ignoré par l'utilisateur/utilisatrice lambda, est la ou les feuilles de style (en CSS, acronyme de Cascading Style Sheet). En revanche, le type suivant aura fort probablement été deviné : le contenu multimédia, dont les images, mais aussi l'audio et la vidéo. On peut après revenir à de l'oublié et du technique avec le ou les éventuels scripts, avec JavaScript comme langage web devenu hégémonique. On pourrait continuer avec les polices de caractères depuis CSS3 et probablement d'autres choses encore, mais on s'arrêtera là.

Après cet interlude, qui a son intérêt contrairement à ce qu'on pourrait penser, revenons à notre sujet technique initial, à savoir HTTP. Et en fait, la pertinence de ce détour va être immédiat ! Comment le navigateur web fait-il pour afficher une page web comme un tout cohérent alors qu'elle peut être composée de plusieurs éléments ? Pour commencer, il doit récupérer l'élément de base, qui est la page HTML. Ensuite il doit l'analyser pour découvrir le ou les éventuels documents qui y sont demandés. Après ça, il peut aller les récupérer, ou du moins tenter de le faire avec l'adresse indiquée (qui peut ne plus être valide ou pointée vers un serveur web en incapacité, quand çe ne vient d'une mauvaise connexion à Internet). Et comment fait-il pour aller les chercher, comment dialogue t'il via le réseau ? Avec HTTP, pardi !

Venons maintenant à HTTP 1, c'est-à-dire à la première version majeure de ce protocole ordinatique de communication. Il ne permet de ne demander qu'un élément à la fois. Du coup, il faut faire autant de requêtes HTTP qu'il y a d'éléments recherchés. Quand les requêtes sont faites à des serveurs différents, c'est inévitable, pas moyen de faire autrement. En revanche, s'il y a plusieurs requêtes qui concernent le même serveur, on pourrait aimer demander tous les éléments concernés en une seule requête. De plus, s'il y a des éléments sur le même serveur que la page web de base (au format HTML), il pourrait être sympathique qu'il nous les envoie en même temps que la page web de base. Mais ces choses là, HTTP 1 ne sait pas les faire. En revanche, HTTP 2 et plus ont introduit de quoi les faire et donc de quoi être plus efficace pour les mêmes données.

Sachant cela, n'est-il alors pas évident qu'il faudrait, autant pour l'écologie que l'expérience utilisateur/utilisatrice, mettre HTTP 1 à la poubelle au profit d'une version plus récente ? D'un point de vue technologique, on ne peut que répondre oui. Mais la technologie n'est pas le seul facteur. En effet, c'est indiscutablement pertinent pour les mêmes données et une portion de celles-ci. En revanche, il peut être mieux d'envoyer moins de données avec HTTP 1 que plus avec HTTP 2+, or le surcroit de performance technologique de HTTP 2+ peut être favorable à envoyer plus de données et qu'à la fin se soit potentiellement moins performant.

Et ce n'est pas là une spéculation, car ça a largement pu être constaté. Les ordinateurs sont devenus plus performants, tout comme les protocoles et les logiciels, pourtant afficher une page web n'est pas pour autant devenu plus rapide. Certes, pour la même page web, il est indéniable que c'est plus rapide. Cependant la manière de concevoir les pages web a évolué et ce en très grande partie de par les nouvelles possibilités offertes par les gains de performances, comme le passage de HTTP 1 à HTTP 2 (du moins avec les clients gérant une version plus récente que la première), et la complexification des logiciels (nouvelles possibilités de CSS et JavaScript, gestion intégrée et sans module complémentaire de l'audio et la vidéo et potentiellement avec DRM, possibilité de faire du XPath et du XSLT, etc.).

La généralisation de l'adoption de HTTP 2+ contribue à cette tendance de facilitation et d'acceptabilité pour des pages web plus lourdes, encore et toujours plus lourdes. On pourrait rétorquer que ce n'est qu'un possible. C'est vrai, mais c'est un argument faible. Il ne faut pas se leurrer : la technologie n'est pas neutre, la manière dont elle est faite et ce qu'elle permet en retour a un impact sur les gens et sociétés qui s'en dote, même si celui-ci peut être différent dans son fond et son intensité selon les personnes (individuelles ou morales). De plus, après s'être octroyé un surplus de puissance sans l'avoir encadré pour le juguler, pourquoi n'en ferait-on pas pleinement usage ? Un·e spinoziste qui passerait par là, répondrez avec sa logique "géométrique" qu'une puissance s'exerce autant qu'elle peut, c'est-à-dire autant que ça lui est permis par une ou des forces contraires.

Il nous faut rajouter à cela que HTTP 2+ n'est par rapport à HTTP 1 qu'un vecteur de performance parmi d'autres et qui ne touche pas à quelque chose d'anecdotique. En effet, HTTP sert à récupérer des données, or elles sont pour le moins pour beaucoup. De ce fait, de par la place qu'il occupe et non ses caractéristiques technologiques (qui connaissent des variations avec les versions), HTTP est structurant. Mais pourquoi en pratique ? Si un surplus de performance de HTTP permet d'avoir le même ressenti utilisateur/utilisatrice pour plus de données récupérées et que rien ne va par ailleurs contre ce surplus de données, son adoption massive rend envisageable d'en envoyer plus. Or des données ne sont pas envoyées pour le plaisir, mais pour être traitées, et le traitement associé a un coût, qui peut être supérieur à l'économie réalisée avec une version plus performante de HTTP. De plus, le traitement n'a pas qu'un coût dans son instant, il en a aussi un par l'usure, mais aussi par sa possibilité même. En effet, plus le traitement est lourd, plus l'est aussi la machine minimum et/ou le logiciel minimum (en faisant là l'hypothèse simplificatrice qu'il y aurait une manière objective d'évaluer objectivement pour la réalisation de tous les traitements possibles, car en réalité il est erroné de parler de "machine minimum" et "logiciel minimum" puisque des attributs de ceux-ci peuvent en compenser d'autres).

Pourrait-on conclure un jour ? HTTP 1 et l'écologie, qu'en penser ? On peut résumer le propos comme suit. HTTP 1 est inférieur en terme de performance technologique et est de ce point de vue restreint inférieur écologiquement. Cependant la technologie n'est pas neutre. De plus, quand elle est déployée, à plus forte raison quand elle l'est massivement et sur le temps long, elle influe sur les individus et collectifs en faisant un usage non-marginal. Du coup, bien que son impact direct, purement technologique, puisse lui être positif, cela n'indique rien sur l'impact indirect, qui est le produit d'un rapport entre la technologie et les gens l'utilisant mais surtout les collectifs l'utilisant (bien que ce ne soit pas antinomique, puisque les collectifs sont composées de gens), et cet impact indirect peut avoir une part négative supérieure aux bienfaits.

Et pour ce qui est du cas spécifique de HTTP 2+, et donc par ricochet de HTTP 1, on a comme l'intuition qu'il a été écologiquement défavorable en contribuant à rendre plus acceptable de faire des pages web plus lourdes avec plus de données à traiter (plus d'images, plus de scripts, rajouts de police de caractères au lieu de se contenter de celles installées sur les systèmes des webonautes, etc.) et en s'inscrivant dans une période historique dont c'était clairement la tendance. Et si on revenait à un Web plus simple ? Revenir à HTTP 1 seulement ne serait-il pas une bonne mesure (bien que notoirement insuffisante) pour y pousser structurellement ?