Un Web « low-tech », « sobre », « frugal»… ce n’est pas une mode, mais un mouvement de fond qui va au-delà de la prise de conscience et commence à s’installer dans les pratiques. C’est pourquoi sans doute Nathalie a choisi d’associer recherche d’informations et expérimentation dans sa démarche d’éco-conception, c’est après tout la meilleure façon d’apprendre et progresser. Les commentaires comme toujours sont ouverts et modérés.
Bilan du défi « avance rapide »
par Nathalie
Nous sommes début avril 2021, voilà maintenant un mois que je m’intéresse aux impacts du numérique sur notre planète. Un mois que je lis tout ce que je peux trouver sur ce sujet et plus particulièrement sur l’éco-conception du numérique. Un mois que j’apprends intensivement sur ce sujet passionnant. Un mois que j’écris sur chaque découverte ou inspiration. Ce fut un mois intense et passionnant. Merci à celles et ceux qui ont pris le temps de me lire et d’écrire un commentaire, que ce soit pour m’encourager ou confronter leurs opinions. Certains sont plus en avance que moi sur le sujet et m’ont apporté leur contribution pour enrichir ce blog.
Je vais continuer à apprendre et à écrire ici au fil de mon chemin. De manière moins soutenue et peut-être un contenu un peu différent parfois. J’aimerais mettre en application ce que j’ai appris. Peut-être en commençant par l’analyse de sites web, décortiquer ensemble les choix de design et les confronter à mes récentes connaissances en éco-conception. Tout n’est pas encore décidé, d’ailleurs si vous avez des idées ou des choses que vous aimeriez voir ici, n’hésitez pas à m’en faire part en commentaires.
Bilan du défi “avance rapide”
Voici un bilan de ces 30 jours d’apprentissage intensif, défi que j’avais baptisé “avance rapide” (ici l’article sur le lancement du défi).
Articles publiés
J’ai lu des dizaines et des dizaines d’articles sur le sujet, participé à deux conférences et lu également deux livres pour lesquels j’ai mis le lien des chroniques un peu plus bas. J’ai découvert de nombreuses statistiques dont certaines qui m’ont beaucoup choquée et que j’ai regroupées ici. J’ai publié 29 articles (en excluant les articles sur le lancement et le bilan du défi que vous êtes en train de lire), un mélange entre apprentissage théorique, bonnes pratiques concrètes et inspirations. Je vous remets les liens de chaque article ci-dessous, classés par catégorie.
Au fil de mon apprentissage, j’ai également appliqué concrètement certaines actions sur le blog:
– non utilisation du blanc dans le design du blog (le blanc est la couleur la plus consommatrice en terme d’énergie)
– application de la méthode Marie Kondo, par exemple en utilisant des images uniquement lorsqu’elles servent à la compréhension
– optimisation des images avec ImageOptim (40% de réduction de poids en moyenne)
– mise en place d’un CDN pour réduire la distance à parcourir pour chaque requête (une bonne pratique dont je n’ai pas encore parlé mais j’y dédierai un article prochainement)
– j’essaie de rédiger des titres clairs pour éviter les mauvaises surprises et des chargements de page inutiles
Pour le moment, le score obtenu pour la page d’accueil du blog (www.webdesignfortheplanet.com) est plutôt satisfaisant. J’espère le maintenir dans le futur 🙂
En conclusion
J’espère que vous avez appris aussi et que certains articles vous ont interpellés, fait prendre conscience de l’impact de nos choix UX ou UI notamment dans la construction de nos sites web et, pourquoi pas, carrément donné envie de changer les choses dans nos métiers du numérique. N’hésitez pas à partager vos ressentis avec moi sur tout ça, ça m’intéresse de vous lire 🙂
J’ai encore beaucoup à apprendre sur ce sujet, je vais continuer à creuser, lire, analyser et expérimenter à mon rythme. Si vous avez des recommandations ou des suggestions de sujets que vous aimeriez que je creuse, n’hésitez pas à m’en faire part en commentaires de cet article.
Le Web est-il devenu trop compliqué ?
Le Web, tout le monde s’en sert et beaucoup en sont très contents. Mais, même parmi ceux et celles qui sont ravi·es de l’utiliser, il y a souvent des critiques. Elles portent sur de nombreux aspects et je ne vais pas essayer de lister ici toutes ces critiques. Je vais parler d’un problème souvent ressenti : le Web n’est-il pas devenu trop compliqué ?
À noter : cet article bénéficie désormais d’une version audio.
Merci à Sualtam, auteur de lectureaudio.fr pour cette contribution active.
Je ne parle pas de la complexité pour l’utilisateur, par exemple des problèmes qu’il ou elle peut avoir avec telle ou telle application Web, ou tel formulaire incompréhensible ou excluant. Non, je parle de la complexité des nombreuses technologies sous-jacentes. Alors, si vous n’êtes pas technicien·ne, vous avez peut-être envie d’arrêter votre lecture ici en pensant qu’on ne parlera que de technique. Mais ce n’est pas le cas, cet article est pour tous et toutes. (Ceci dit, si vous arrêtez votre lecture pour jouer avec le chat, manger un bon plat, lire un livre passionnant ou faire des câlins à la personne appropriée, cela ne me dérange pas et je vous souhaite un agréable moment.)
Mais revenons à l’objection « OK, les techniques utilisées dans le Web sont compliquées mais cela ne concerne que les développeuses et développeurs, non ? » Eh bien non car cette complication a des conséquences pour tous et toutes. Elle se traduit par des logiciels beaucoup plus complexes, donc elle réduit la concurrence, très peu d’organisations pouvant aujourd’hui développer un navigateur Web. Elle a pour conséquence de rendre l’utilisation du Web plus lente : bien que les machines et les réseaux aient nettement gagné en performance, le temps d’affichage d’une page ne cesse d’augmenter. Passer à la fibre ou à la 5G ne se traduira pas forcément par un gain de temps, puisque ce sont souvent les calculs nécessaires à l’affichage qui ralentissent la navigation. Et enfin cette complication augmente l’empreinte environnementale du Web, en imposant davantage d’opérations aux machines, ce qui pousse au remplacement plus rapide des terminaux.
L’insoutenable lourdeur du Web
Une page Web d’aujourd’hui n’est en effet pas une simple description d’un contenu. Elle inclut la « feuille de style », rédigée dans le langage CSS, qui va indiquer comment présenter la page, du JavaScript, un langage de programmation qui va être exécuté pour faire varier le contenu de la page, des vidéos, et d’autres choses qui souvent distraient du contenu lui-même. Je précise que je ne parle pas ici des applications tournant sur le Web (comme une application d’accès au courrier électronique, ou une application de gestion des évènements ou l’application maison utilisée par les employés d’une organisation pour gérer leur travail), non, je parle des pages Web de contenu, qui ne devraient pas avoir besoin de toute cette artillerie.
Du fait de cette complexité, il n’existe aujourd’hui que quatre ou cinq navigateurs Web réellement distincts. Écrire un navigateur Web aujourd’hui est une tâche colossale, hors de portée de la très grande majorité des organisations. La concurrence a diminué sérieusement. La complexité technique a donc des conséquences stratégiques pour le Web. Et ceci d’autant plus qu’il n’existe derrière ces navigateurs que deux moteurs de rendu, le cœur du navigateur, la partie qui interprète le langage HTML et le CSS et dessine la page. Chrome, Edge et Safari utilisent le même moteur de rendu, WebKit (ou l’une de ses variantes).
Et encore tout ne tourne pas sur votre machine. Derrière votre écran, l’affichage de la moindre page Web va déclencher d’innombrables opérations sur des machines que vous ne voyez pas, comme les calculs des entreprises publicitaires qui vont, en temps réel, déterminer les « meilleures » publicités à vous envoyer dans la figure ou comme l’activité de traçage des utilisateurs, notant en permanence ce qu’ils font, d’où elles viennent et de nombreuses autres informations, dont beaucoup sont envoyées automatiquement par votre navigateur Web, qui travaille au moins autant pour l’industrie publicitaire que pour vous. Pas étonnant que la consommation énergétique du numérique soit si importante. Et ces calculs côté serveur ont une grande influence sur la capacité du serveur à tenir face à une charge élevée, comme on l’a vu pendant les confinements Covid-19. Les sites Web de l’Éducation Nationale ne tenaient pas le coup, même quand il s’agissait uniquement de servir du contenu statique.
La surveillance coûte cher
La complexité du Web cache en effet également cette activité de surveillance, pratiquée aussi bien par les entreprises privées que par les États. Autrefois, acheter un journal à un kiosque et le lire étaient des activités largement privées. Aujourd’hui, toute activité sur le Web est enregistrée et sert à nourrir les bases de données du monde de la publicité, ou les fichiers des États. Comme exemple des informations envoyées par votre navigateur, sans que vous en ayez clairement connaissance, on peut citer bien sûr les fameux cookies. Ce sont des petits fichiers choisis par le site Web et envoyés à votre navigateur. Celui-ci les stockera et, lors d’une visite ultérieure au même site Web, renverra le cookie. C’est donc un outil puissant de suivi de l’utilisateur. Et ne croyez pas que, si vous visitez un site Web, seule l’organisation derrière ce site pourra vous pister. La plupart des pages Web incluent en effet des ressources extérieures (images, vidéos, boutons de partage), pas forcément chargés depuis le site Web que vous visitez et qui ont eux aussi leurs cookies. La loi Informatique et Libertés (et, aujourd’hui, le RGPD) impose depuis longtemps que les utilisateurs soient prévenus de ce pistage et puissent s’y opposer, mais il a fallu très longtemps pour que la CNIL tape sur la table et impose réellement cette information des utilisateurs, le « bandeau cookies ». Notez qu’il n’est pas obligatoire. D’abord, si le site Web ne piste pas les utilisateurs, il n’y a pas d’obligation d’un tel bandeau, ensuite, même en cas de pistage, de nombreuses exceptions sont prévues.
Un bandeau cookies. Notez qu’il n’y a pas de bouton Refuser.
Les bandeaux cookies sont en général délibérément conçus pour qu’il soit difficile de refuser. Le but est que l’utilisateur clique rapidement sur « Accepter » pour en être débarrassé, permettant ainsi à l’entreprise qui gère le site Web de prétendre qu’il y a eu consentement.
Désolé de la longueur de ce préambule, d’autant plus qu’il est très possible que, en tant que lectrice ou lecteur du Framablog, vous soyez déjà au courant. Mais il était nécessaire de revenir sur ces problèmes du Web pour mieux comprendre les projets qui visent à corriger le tir. Notez que les évolutions néfastes du Web ne sont pas qu’un problème technique. Elles sont dues à des raisons économiques et politiques et donc aucune approche purement technique ne va résoudre complètement le problème. Cela ne signifie pas que les techniciens et techniciennes doivent rester les bras croisés. Ils et elles peuvent apporter des solutions partielles au problème.
Bloquer les saletés
Première approche possible vers un Web plus léger, tenter de bloquer les services néfastes. Tout bon navigateur Web permet ainsi un certain contrôle de l’usage des cookies. C’est par exemple ce que propose Firefox dans une rubrique justement nommée « Vie privée et sécurité ».
Le menu de Firefox pour contrôler notamment les cookies
On peut ainsi bloquer une partie du système de surveillance. Cette approche est très recommandée mais notez que Firefox vous avertit que cela risque d’ « empêcher certains sites de fonctionner ». Cet avertissement peut faire hésiter certains utilisateurs, d’autant plus qu’avec les sites en question, il n’y aura aucun message clair, uniquement des dysfonctionnements bizarres. La plupart des sites Web commerciaux sont en effet développés sans tenir compte de la possibilité que le visiteur ait activé ces options. Si le site de votre banque ne marche plus après avoir changé ces réglages, ne comptez pas sur le support technique de la banque pour vous aider à analyser le problème, on vous dira probablement uniquement d’utiliser Google Chrome et de ne pas toucher aux réglages. D’un côté, les responsables du Web de surveillance disent qu’on a le choix, qu’on peut changer les réglages, d’un autre côté ils exercent une pression sociale intense pour qu’on ne le fasse pas. Et puis, autant on peut renoncer à regarder le site Web d’un journal lorsqu’il ne marche pas sans cookies, autant on ne peut guère en faire autant lorsqu’il s’agit de sa banque.
De même qu’on peut contrôler, voire débrayer les cookies, on peut supprimer le code Javascript. À ma connaissance, Firefox ne permet pas en standard de le faire, mais il existe une extension nommée NoScript pour le faire. Comme avec les cookies, cela posera des problèmes avec certains sites Web et, pire, ces problèmes ne se traduiront pas par des messages clairs mais par des dysfonctionnements. Là encore, peu de chance que le logiciel que l’entreprise en question a chargé de répondre aux questions sur Twitter vous aide.
Enfin, un troisième outil pour limiter les divers risques du Web est le bloqueur de publicité. (Personnellement, j’utilise uBlock Origin.)
uBlock Origin sur le site du Monde, où il a bloqué trois pisteurs et publicités. On voit aussi à gauche la liste des sites chargés automatiquement par votre navigateur quand vous regardez Le Monde.
Absolument indispensable à la fois pour éviter de consacrer du temps de cerveau à regarder les publicités, pour la sécurité (les réseaux de distribution de la publicité sont l’endroit idéal pour diffuser du logiciel malveillant) et aussi pour l’empreinte environnementale, le bloqueur empêchant le chargement de contenus qui feront travailler votre ordinateur pour le profit des agences de publicité et des annonceurs.
Un navigateur Web léger ?
Une solution plus radicale est de changer de navigateur Web. On peut ainsi préférer le logiciel Dillo, explicitement conçu pour la légèreté, les performances et la vie privée. Dillo marche parfaitement avec des sites Web bien conçus, mais ceux-ci ne sont qu’une infime minorité. La plupart du temps, le site sera affiché de manière bizarre. Et on ne peut pas le savoir à l’avance ; naviguer sur le Web avec Dillo, c’est avoir beaucoup de mauvaises surprises et seulement quelques bonnes (le Framablog, que vous lisez en ce moment, marche très bien avec Dillo).
Le site de l’Élysée vu par Dillo. Inutilisable (et pas par la faute de Dillo mais par le choix de l’Élysée d’un site spectaculaire plutôt qu’informatif).
Autre navigateur « alternatif », le Tor Browser. C’est un Firefox modifié, avec NoScript inclus et qui, surtout, ne se connecte pas directement au site Web visité mais passe par plusieurs relais du réseau Tor, supprimant ainsi un moyen de pistage fréquent, l’adresse IP de votre ordinateur. Outre que certains sites ne réagissent pas bien aux réglages du Tor Browser, le passage par le réseau Tor se traduit par des performances décrues.
Toutes ces solutions techniques, du bloqueur de publicités au navigateur léger et protecteur de la vie privée, ont un problème commun : elles sont perçues par les sites Web comme « alternatives » voire « anormales ». Non seulement le site Web risque de ne pas fonctionner normalement mais surtout, on n’est pas prévenu à l’avance, et même après on n’a pas de diagnostic clair. Le Web, pourtant devenu un écosystème très complexe, n’a pas de mécanismes permettant d’exprimer des préférences et d’être sûr qu’elles sont suivies. Certes, il existe des techniques comme l’en-tête « Do Not Track » où votre navigateur annonce qu’il ne souhaite pas être pisté mais il est impossible de garantir qu’il sera respecté et, vu le manque d’éthique de la grande majorité des sites Web, il vaut mieux ne pas compter dessus.
Gemini, une solution de rupture
Cela a mené à une approche plus radicale, sur laquelle je souhaitais terminer cet article, le projet Gemini. Gemini est un système complet d’accès à l’information, alternatif au Web, même s’il en reprend quelques techniques. Gemini est délibérément très simple : le protocole, le langage parlé entre le navigateur et le serveur, est très limité, afin d’éviter de transmettre des informations pouvant servir au pistage (comme l’en-tête User-Agent du Web) et il n’est pas extensible. Contrairement au Web, aucun mécanisme n’est prévu pour ajouter des fonctions, l’expérience du Web ayant montré que ces fonctions ne sont pas forcément dans l’intérêt de l’utilisateur. Évidemment, il n’y a pas l’équivalent des cookies. Et le format des pages est également très limité, à la fois pour permettre des navigateurs simples (pas de CSS, pas de Javascript), pour éviter de charger des ressources depuis un site tiers et pour diminuer la consommation de ressources informatiques par le navigateur. Il n’y a même pas d’images. Voici deux exemples de navigateurs Gemini :
Le client Gemini Lagrange
Le même site Gemini, vu par un client différent, Elpher
Gemini est un système récent, s’inspirant à la fois de systèmes anciens (comme le Web des débuts) et de choses plus récentes (ainsi, contrairement au Web, le chiffrement du trafic, pour compliquer la surveillance, est systématique). Il reprend notamment le concept d’URL donc par exemple le site d’informations sur les alertes de tempêtes solaires utilisé plus haut à titre d’exemple est gemini://gemini.bortzmeyer.org/presto/. Gemini est actuellement en cours de développement, de manière très ouverte, notamment sur la liste de diffusion publique du projet. Tout le monde peut participer à sa définition. (Mais, si vous voulez le faire, merci de lire la FAQ d’abord, pour ne pas recommencer une question déjà discutée.) Conformément aux buts du projet, écrire un client ou un serveur Gemini est facile et des dizaines de logiciels existent déjà. Le nom étant une allusion aux missions spatiales étatsuniennes Gemini, mais signifiant également « jumeaux » en latin, beaucoup de ces logiciels ont un nom qui évoque le spatial ou la gémellité. Pour la même raison spatiale, les sites Gemini se nomment des capsules, et il y en a actuellement quelques centaines opérationnelles. (Mais, en général, avec peu de contenu original. Gemini ressemble pour l’instant au Web des débuts, avec du contenu importé automatiquement d’autres services, et du contenu portant sur Gemini lui-même.)
On a vu que Gemini est une solution très disruptive et qui ne sera pas facilement adoptée, tant le marketing a réussi à convaincre que, sans vidéos incluses dans la page, on ne peut pas être vraiment heureux. Gemini ne prétend pas à remplacer le Web pour tous ses usages. Par exemple, un CMS, logiciel de gestion de contenu, comme le WordPress utilisé pour cet article, ne peut pas être fait avec Gemini, et ce n’est pas son but. Son principal intérêt est de nous faire réfléchir sur l’accès à l’information : de quoi avons-nous besoin pour nous informer ?
Des pages web légères et moins gourmandes en ressources, du « low-tech » c’est plus écologique probablement, mais c’est aussi une des conditions pour rendre durables des contenus qui ont une fâcheuse tendance à se volatiliser… Jeff Huang est professeur d’informatique et dans la page que Framalang a traduite pour vous, il fait le pari que son contenu sera encore accessible dans dix ans au moins, tout en proposant 7 recommandations pour créer des pages web pérennes.
Il ne s’agit pas de solutions miracles, mais plutôt d’incitations à l’action et au débat, comme il l’écrit :
Cet article est destiné à provoquer et à susciter une action individuelle, et non à proposer une solution complète pour soigner le Web en déclin
Donc il est clair que les conseils qu’il donne sont peut-être incomplets ou critiquables. Certain⋅e⋅s (comme un de nos traducteurs) vont par exemple sursauter de lire que les polices Google peuvent être utilisées car elles sont « probablement déjà dans le cache ». D’autres vont regretter que le recours à l’archivage ne soit pas assez mis en avant comme le fait cipherbliss dans cet article… bref, n’hésitez pas à ajouter des critiques constructives.
N’hésitez pas non plus à nous dire s’il existe vraiment des contenus web qui méritent selon vous d’être maintenus dix ans ou plus, et lesquels (créations et expressions personnelles, ressources des Communs, etc.), ou bien si vous acceptez avec fatalisme ou satisfaction que les pages web, comme tout le reste, finissent par disparaître…
Les commentaires, comme toujours sur ce blog, sont ouverts et modérés.
Pour un professeur, la fin de l’année est l’occasion de faire le ménage et de se préparer pour le semestre à venir. Je me suis retrouvé à effacer de vieux marque-pages, eh oui, des marque-pages : cette fonctionnalité des navigateurs autrefois si appréciée qui paraît avoir perdu la bataille contre la « complétion automatique dans la barre d’adresse ». Mais ce geste nostalgique de nettoyage a fini par me déprimer.
Les uns après les autres, les marque-pages m’ont mené vers des liens morts. Disparus, de superbes écrits de kuroShin sur la culture technologique ainsi qu’une série de puzzles mathématiques et les discussions associées des universitaires que mon père m’avait présentés ; disparus aussi les tutoriels d’ingénierie inverse de Woodman qui datent de mes années d’étude, avec lesquels j’ai découvert le sentiment d’avoir le pouvoir sur les logiciels ; même mes plus récents marque-pages ont disparu, une série d’articles exposant sur Google+ la non-conformité des chargeurs usb-c avec les normes…
Ce n’est pas seulement une question de liens fichus, c’est le problème de la difficulté croissante de maintenir en vie des contenus indépendants sur le Web, conduisant à une dépendance à des plateformes et à des formats de publication qui s’empilent de façon chronologique (blogs, fils, tweets…)
Bien sûr j’ai moi aussi contribué au problème. Un article que j’ai publié il y a sept ans comprend un résumé initial dans lequel un lien vers une démo a été remplacé par une page de spam avec une image de citrouille. C’est en partie à cause de la flemme de devoir renouveler et de maintenir une application web fonctionnelle année après année.
J’ai recommandé à mes étudiants de publier des sites web avec Heroku et des portfolios avec Wix. Mais toute plateforme au contenu irremplaçable meurt un jour. Geocities, LiveJournal, what.cd, maintenant Yahoo Groups. Un jour, Medium, Twitter et même les services d’hébergement comme GitHub Pages seront pillés puis jetés lorsqu’ils ne pourront plus se développer ou n’auront pas trouvé de modèle économique viable.
C’est un problème de nature plurielle.
Tout d’abord, maintenir du contenu demande du travail. Le contenu peut avoir besoin d’être mis à jour pour rester pertinent et devra éventuellement être ré-hébergé. Une grande partie du contenu – ce qui était autrefois la grande majorité du contenu – a été mise en place par des individus. Mais les particuliers (peut-être vous ?) finissent par se désintéresser, si bien qu’un jour, vous ne voudrez peut-être plus vous occuper de la migration d’un site web vers un nouvel hébergeur.
Deuxièmement, le nombre croissant de bibliothèques et de frameworks rend le Web plus sophistiqué, mais également plus complexe. Il y a d’abord eu jquery, puis bootstrap, npm, angular, grunt, webpack, et bien d’autres. Si vous êtes un développeur web qui se tient au courant des dernières nouveautés, alors ce n’est pas un problème.
Mais dans le cas contraire, vous êtes peut-être programmeur de systèmes embarqués, directeur technique d’une start-up, un développeur Java d’entreprise ou un doctorant de chimie. Vous avez sans doute trouvé le moyen de mettre en place un serveur web et sa chaîne d’outils, mais continuerez-vous à le faire d’une année à l’autre, d’une décennie à l’autre ? Probablement pas ! Et lorsque, l’année suivante, vous rencontrerez un problème de dépendance à un paquet ou que vous découvrirez comment régénérer vos fichiers html, vous pourriez abandonner et zipper les fichiers pour vous en occuper « plus tard ».
Même les piles technologiques simples comme les générateurs de sites statiques (par exemple, Jekyll) nécessitent du travail et cesseront de fonctionner à un moment donné. Vous tombez dans l’enfer des dépendances aux paquets NPM, et vous oubliez la commande pour réaliser un déploiement. Et avoir un site web avec plusieurs pages html est complexe ; comment savoir comment chaque page est liée aux autres : « index.html.old », une copie de « about.html » « index.html (1) », « nav.html » ?
Troisièmement, et cela a déjà été rapporté par d’autres (et même réfuté), la disparition du Web « public » au profit du mobile et des applications web, des jardins clos (telles que les pages Facebook), du chargement en temps réel des WebSockets et de l’AMP diminue la proportion même de la toile dans la toile mondiale, qui ressemble désormais davantage à une toile continentale qu’à une « toile mondiale » (World Wide Web).
Alors, face à ces problèmes, que pouvons-nous faire ? Ce n’est pas un problème si simple qu’il puisse être résolu dans cet article. La Wayback Machine et archive.org permettent de conserver certains contenus plus longtemps. Et il arrive qu’un individu altruiste relocalise le contenu ailleurs.
Mais la solution se trouve sur plusieurs fronts. Comment créer un contenu web qui puisse durer et être maintenu pendant au moins dix ans ? Étudiant l’interaction homme-machine, je pense naturellement aux parties prenantes que nous n’aidons pas : actuellement, la mise en ligne de contenu web est optimisée soit pour le développeur web professionnel (qui utilise les derniers frameworks et flux de travail), soit pour l’utilisateur non averti (qui utilise une plateforme).
Mais je pense que nous devrions considérer à la fois 1) le « responsable » occasionnel du contenu web, quelqu’un qui ne reste pas constamment à jour avec les dernières technologies web, ce qui signifie que le site web doit avoir de faibles besoins de maintenance ; 2) et les robots d’indexation qui préservent le contenu et les archiveurs personnels, « archiveur » implique que le site web doit être facile à sauvegarder et à interpréter.
Ma proposition consiste donc en sept lignes directrices non conventionnelles sur la manière dont nous traitons les sites web conçus pour être informatifs, pour les rendre faciles à entretenir et à préserver. Ma suggestion est que le responsable de la maintenance s’efforce de maintenir le site pendant au moins 10 ans, voire 20 ou 30 ans. Il ne s’agit pas nécessairement de points de vue controversés, mais d’aspirations qui ne sont pas courantes − un manifeste pour un site web durable.
1.Revenez à du HTML/CSS « Vanilla » (NdT : le plus simple, sans JavaScript) – Je pense que nous avons atteint le point où le html/css est plus puissant et plus agréable à utiliser que jamais. Au lieu de commencer avec un modèle obèse bourré de fichiers « .js », il est maintenant possible de simplement écrire en HTML, à partir de zéro. Les CSS « Flexbox » et « Grid », le canvas, les Selectors, le box-shadow, l’élément vidéo, le filtre, etc. éliminent une grande partie du besoin de bibliothèques JavaScript. Nous pouvons éviter le jQuery et le Bootstrap, car ils deviennent de toute façon moins pertinents. Plus il y a de bibliothèques intégrées au site web, plus celui-ci devient fragile. Évitez les polyfills et les préfixes CSS, et n’utilisez que les attributs CSS qui fonctionnent sur tous les navigateurs. Et validez fréquemment votre HTML ; cela pourrait vous éviter un mal de tête à l’avenir lorsque vous rencontrez un bogue.
2.Ne réduisez pas ce HTML. Réduire (compresser) votre HTML et les CSS/JS associés vous semblera peut-être une précieuse économie de bande passante, et toutes les grandes entreprises le font. Pourquoi ne pas le faire ? Eh bien, vous n’économisez pas beaucoup parce que vos pages web doivent être compressées avant d’être envoyées sur le réseau, donc la réduction préventive de votre contenu compte probablement très peu dans l’économie de bande passante, voire pas du tout. Mais même si cela permettait d’économiser quelques octets (ce n’est après tout que du texte), vous devez maintenant avoir un processus de construction et l’ajouter à votre flux de travail, de sorte que la mise à jour d’un site web devient plus complexe. En cas de bogue ou d’incompatibilité future dans le HTML, le format minimisé est plus difficile à déboguer. De plus, il est peu convivial pour vos utilisateurs ; de nombreuses personnes commencent à utiliser le HTML en cliquant sur « Voir la source »1, et la réduction de votre HTML empêche cet idéal d’apprentissage en regardant ce qui est fait. Réduire le HTML ne préserve pas sa qualité pédagogique, et ce qui est archivé n’est que le tas de code résultant.
3.Préférez maintenir une page plutôt que plusieurs. Plusieurs pages sont difficiles à maintenir. Vous pouvez oublier quelle page renvoient à quoi, et cela nécessite également la mise en place de modèles pour limiter les redondances. Combien de pages une personne peut-elle réellement maintenir ? Avoir un seul fichier, probablement juste un « index.html », est simple et facile à retenir. Profitez de ce défilement vertical infini. Vous n’aurez jamais besoin de fouiller dans vos fichiers ou de faire du grep pour voir où se trouve un certain contenu. Et comment gérer les multiples versions de ce fichier ? Devriez-vous utiliser git ? Les placer dans un dossier « old/ » ? J’aime l’approche simple qui consiste à nommer les anciens fichiers avec la date à laquelle ils ont été retirés, comme index.20191213.html. L’utilisation du format ISO de la date permet de trier facilement, et il n’y a pas de confusion entre les formats de date américain et européen. Si j’ai plusieurs versions en une journée, j’utiliserais un style similaire à celui qui est habituel dans les fichiers journaux, index.20191213.1.html. Un effet secondaire agréable est que vous pouvez alors accéder à une version plus ancienne du fichier si vous vous souvenez de la date, sans vous connecter à la plateforme d’hébergement web.
4.Mettez fin à toutes les formes de liaison automatique (hotlinking). Ce mot d’avertissement semble avoir disparu du vocabulaire internet, mais c’est l’une des raisons pour lesquelles j’ai vu un site web parfaitement bon s’effondrer sans raison. Cessez d’inclure directement des images provenant d’autres sites web, cessez d’« emprunter » des feuilles de style en vous contentant de créer des liens vers celles-ci, et surtout cessez de créer des liens vers des fichiers JavaScript, même ceux qui sont hébergés par les développeurs d’origine. Les liaisons automatiques sont généralement considérées comme impolies car vos visiteurs utilisent la bande passante de quelqu’un d’autre, elles ralentissent l’expérience utilisateur, permettent un autre site web de pister vos utilisateurs et, pire encore, si l’endroit auquel vous vous connectez modifie la structure de ses dossiers ou se déconnecte tout simplement, la panne se répercute également sur votre site web. Google Analytics est inutile ; stockez vos propres journaux de serveur et configurez GoAccess ou découpez-les comme vous le souhaitez, ce qui vous donnera des statistiques plus détaillées. Ne donnez pas vos journaux à Google gratuitement.
5.N’utilisez que les 13 polices de caractères adaptées au Web – nous nous concentrons d’abord sur le contenu, comprenez : les caractères décoratifs et inhabituels sont complètement inutiles. Maintenez un petit éventail et les 13 polices de caractères adaptées au Web. Peut-être avez-vous vraiment besoin d’une police de caractères néo-grotesque qui ne soit pas Arial/Helvetica, ou d’une police de caractères géométriques. Dans ce cas, utilisez le minimum nécessaire, comme Roboto (pour le néo-grotesque) et Open Sans (pour le géométrique) ; ce sont les deux polices les plus populaires de Google Fonts, il est donc probable qu’elles soient déjà en cache sur l’ordinateur de vos utilisateurs. Outre ces polices, votre objectif doit être de fournir le contenu à l’utilisateur de manière efficace et de faire en sorte que le choix de la police soit invisible, plutôt que de flatter votre ego en matière de conception. Même si vous utilisez les polices Google, elles n’ont pas besoin d’être liées automatiquement (hotlink). Téléchargez le sous-ensemble dont vous avez besoin et fournissez-les localement à partir de vos propres dossiers.
6.Compressez vos images de manière obsessionnelle. Ce sera plus rapide pour vos utilisateurs, moins gourmand en espace d’archivage et plus facile à maintenir lorsque vous n’avez pas à sauvegarder un énorme dossier. Vos images peuvent avoir la même haute qualité, mais être plus petites. Minimisez vos SVG, compressez sans perte vos PNG, générez des JPEG pour qu’ils correspondent exactement à la largeur de l’image. Cela vaut la peine de passer du temps à trouver la meilleure façon de compresser et de réduire la taille de vos images sans perte de qualité. Et une fois que WebP sera pris en charge par Safari, passez à ce format. Réduisez impitoyablement la taille totale de votre site web et gardez-la aussi petite que possible. Chaque Mo peut coûter cher à quelqu’un ; en effet mon opérateur de téléphonie mobile (Google Fi) facture un centime (de dollar) par Mo de données. Ainsi, un site web de 25 Mo, assez courant de nos jours, coûte lui-même 25 centimes, soit à peu près autant qu’un journal quand j’étais enfant.
7.Éliminez le risque de rupture d’URL. Il existe des services de contrôle qui vous indiqueront quand votre URL est en panne, ce qui vous évitera de réaliser un jour que votre page d’accueil ne charge plus depuis un mois et que les moteurs de recherche l’ont désindexée. Car 10 ans, c’est plus long que ce que la plupart des disques durs ou des systèmes d’exploitation sont censés durer. Mais pour éliminer le risque de panne totale d’une URL, mettez en place un second service de contrôle. En effet, si le premier s’arrête pour une raison quelconque (passage à un modèle payant, fermeture, oubli de renouvellement, etc.), vous recevrez toujours une notification lorsque votre URL est hors service, puis vous réaliserez que l’autre service de surveillance est hors service parce que vous n’avez pas reçu la deuxième notification. N’oubliez pas que nous essayons de maintenir un service pendant plus de 10 ans (idéalement bien plus longtemps, même 30 ans), donc beaucoup de services vont s’arrêter pendant cette période, donc deux services de surveillance, c’est plus sûr…
Après avoir fait cela, placez un texte dans le pied de page, « La page a été conçue pour durer », avec un lien vers cette page expliquant ce que cela signifie. Ces quelques mots attestent que le responsable fera de son mieux pour suivre les idées de ce manifeste.
Avant que vous ne protestiez, il est évident que cela n’est pas adapté pour les applications web. Si vous créez une application, alors créez votre application web ou mobile avec le flux de travail dont vous avez besoin. Je ne connais pas une seule application web qui ait fonctionné de manière identique pendant 10 ans (sauf le tutoriel python de Philip Guo, en raison de sa stratégie minimaliste de maintenance), donc cela semble être une cause perdue de toute façon. Ce n’est pas non plus adapté pour les sites web maintenus par une organisation comme Wikipédia ou Twitter. Vous faites votre truc, et le salaire d’une équipe informatique est probablement suffisant pour maintenir quelque chose en vie pendant un certain temps.
En fait, il n’est même pas si important de suivre strictement les 7 « règles », car ce sont plus des incitations que des règles impératives.
Mais admettons qu’une petite partie du Web commence à concevoir des sites web dont le contenu est censé durer. Que se passe-t-il alors ? Eh bien, les gens préféreront peut-être créer des liens vers ces sites car leur accès est garanti à l’avenir. Plus généralement, les gens peuvent être plus soucieux de rendre leurs pages plus permanentes. Et les utilisateurs et utilisatrices ainsi que les robots qui archivent économisent de la bande passante lorsqu’ils visitent et stockent ces pages.
Les effets sont à long terme, mais les réalisations sont progressives et peuvent être mises en œuvre par les propriétaires de sites web sans dépendre de quiconque ni attendre un effet de réseau. Vous pouvez le faire dès maintenant pour votre site web, et ce serait déjà un résultat positif. C’est comme utiliser un sac de courses recyclé au lieu d’un sac en plastique, c’est une petite action individuelle.
Cet article est destiné à provoquer et à susciter une action individuelle, et non à proposer une solution complète au déclin de la Toile. Il s’agit d’un petit pas simple pour un système sociotechnique complexe. J’aimerais donc voir cela se produire. J’ai l’intention de maintenir cette page pendant au moins 10 ans.
Merci à mes étudiants en doctorat Shaun Wallace, Nediyana Daskalova, Talie Massachi, Alexandra Papoutsaki, mes collègues James Tompkin, Stephen Bach, mon assistante d’enseignement Kathleen Chai et mon assistant de recherche Yusuf Karim pour leurs commentaires sur les versions précédentes.
On parle beaucoup en ce moment d’une « saturation des réseaux », de « risques pour l’Internet », qui justifieraient des mesures autoritaires et discriminatoires, par exemple le blocage ou le ralentissement de Netflix, pour laisser de la place au « trafic sérieux ». Que se passe-t-il exactement et qu’y a-t-il derrière les articles sensationnalistes ?
La France, ainsi que de nombreux autres pays, est confinée chez elle depuis plusieurs jours, et sans doute encore pour plusieurs semaines. La durée exacte dépendra de l’évolution de l’épidémie de COVID-19. Certains travailleurs télétravaillent, les enfants étudient à la maison, et la dépendance de toutes ces activités à l’Internet a suscité quelques inquiétudes.
On a vu des médias, ou des dirigeants politiques comme Thierry Breton, réclamer des mesures de limitation du trafic, par exemple pour les services vidéo comme Netflix. Les utilisateurs qui ont constaté des lenteurs d’accès à certains sites, ou des messages d’erreur du genre « temps de réponse dépassé » peuvent se dire que ces mesures seraient justifiées. Mais les choses sont plus compliquées que cela, et il va falloir expliquer un peu le fonctionnement de l’Internet pour comprendre.
Le site Web du CNED, inaccessible en raison des nombreux accès (mais le réseau qui y mène marchait parfaitement à ce moment).
Réseaux et services
D’abord, il faut différencier l’Internet et les services qui y sont connectés. Si un élève ou un enseignant essaie de se connecter au site du CNED (Centre National d’Enseignement à Distance) et qu’il récupère un message avec une « HTTP error 503 », cela n’a rien à voir avec l’Internet, et supprimer Netflix n’y changera rien : c’est le site Web au bout qui est surchargé d’activité, le réseau qui mène à ce site n’a pas de problème. Or, ce genre de problèmes (site Web saturé) est responsable de la plupart des frustrations ressenties par les utilisateurs et utilisatrices. Résumer ces problèmes de connexion avec un « l’Internet est surchargé » est très approximatif et ne va pas aider à trouver des solutions aux problèmes. Pour résumer, les tuyaux de l’Internet vont bien, ce sont certains sites Web qui faiblissent. Ou, dit autrement, « Dire que l’Internet est saturé, c’est comme si vous cherchez à louer un appartement à la Grande Motte au mois d’août et que tout est déjà pris, du coup vous accusez l’A7 d’être surchargée et demandez aux camions de ne pas rouler. »
On peut se demander pourquoi certains services sur le Web plantent sous la charge (ceux de l’Éducation Nationale, par exemple) et d’autres pas (YouTube, PornHub, Wikipédia). Il y a évidemment de nombreuses raisons à cela et on ne peut pas faire un diagnostic détaillé pour chaque cas. Mais il faut noter que beaucoup de sites Web sont mal conçus. L’écroulement sous la charge n’est pas une fatalité. On sait faire des sites Web qui résistent. Je ne dis pas que c’est facile, ou bon marché, mais il ne faut pas non plus baisser les bras en considérant que ces problèmes sont inévitables, une sorte de loi de la nature contre laquelle il ne servirait à rien de se révolter. Déjà, tout dépend de la conception du service. S’il s’agit de distribuer des fichiers statiques (des fichiers qui ne changent pas, comme des ressources pédagogiques ou comme la fameuse attestation de circulation), il n’y a pas besoin de faire un site Web dynamique (où toutes les pages sont calculées à chaque requête). Servir des fichiers statiques, dont le contenu ne varie pas, est quelque chose que les serveurs savent très bien faire, et très vite. D’autant plus qu’en plus du Web, on dispose de protocoles (de techniques réseau) spécialement conçus pour la distribution efficace, en pair-à-pair, directement entre les machines des utilisateurs, de fichiers très populaires. C’est le cas par exemple de BitTorrent. S’il a permis de distribuer tous les épisodes de Game of Thrones à chaque sortie, il aurait permis de distribuer facilement l’attestation de sortie ! Même quand on a du contenu dynamique, par exemple parce que chaque page est différente selon l’utilisateur, les auteurs de sites Web compétents savent faire des sites qui tiennent la charge.
Mais alors, si on sait faire, pourquoi est-ce que ce n’est pas fait ? Là encore, il y a évidemment de nombreuses raisons. Il faut savoir que trouver des développeurs compétents est difficile, et que beaucoup de sites Web sont « bricolés », par des gens qui ne mesurent pas les conséquences de leurs choix techniques, notamment en termes de résistance à la charge. En outre, les grosses institutions comme l’Éducation Nationale ne développent pas forcément en interne, elles sous-traitent à des ESN et toute personne qui a travaillé dans l’informatique ces trente dernières années sait qu’on trouve de tout, et pas forcément du bon, dans ces ESN. Le « développeur PHP senior » qu’on a vendu au client se révèle parfois ne pas être si senior que ça. Le développement, dans le monde réel, ressemble souvent aux aventures de Dilbert. Le problème est aggravé dans le secteur public par le recours aux marchés publics, qui sélectionnent, non pas les plus compétents, mais les entreprises spécialisées dans la réponse aux appels d’offre (une compétence assez distincte de celle du développement informatique). Une petite entreprise pointue techniquement n’a aucune chance d’être sélectionnée.
D’autre part, les exigences de la propriété intellectuelle peuvent aller contre celles de la technique. Ainsi, si BitTorrent n’est pas utilisé pour distribuer des fichiers d’intérêt général, c’est probablement en grande partie parce que ce protocole a été diabolisé par l’industrie du divertissement. « C’est du pair-à-pair, c’est un outil de pirates qui tue la création ! » Autre exemple, la recopie des fichiers importants en plusieurs endroits, pour augmenter les chances que leur distribution résiste à une charge importante, est parfois explicitement refusée par certains organismes comme le CNED, au nom de la propriété intellectuelle.
Compter le trafic réseau
Bon, donc, les services sur le Web sont parfois fragiles, en raison de mauvais choix faits par leurs auteurs, et de réalisations imparfaites. Mais les tuyaux, eux, ils sont saturés ou pas ? De manière surprenante, il n’est pas facile de répondre à cette question. L’Internet n’est pas un endroit unique, c’est un ensemble de réseaux, eux-mêmes composés de nombreux liens. Certains de ces liens ont vu une augmentation du trafic, d’autres pas. La capacité réseau disponible va dépendre de plusieurs liens (tous ceux entre vous et le service auquel vous accédez). Mais ce n’est pas parce que le WiFi chez vous est saturé que tout l’Internet va mal ! Actuellement, les liens qui souffrent le plus sont sans doute les liens entre les FAI (Fournisseurs d’Accès Internet) et les services de vidéo comme Netflix. (Si vous voyez le terme d’appairage – peering, en anglais – c’est à ces liens que cela fait allusion.) Mais cela n’affecte pas la totalité du trafic, uniquement celui qui passe par les liens très utilisés. La plupart des FAI ne fournissent malheureusement pas de données publiques sur le débit dans leurs réseaux, mais certains organismes d’infrastructure de l’Internet le font. C’est le cas du France-IX, le principal point d’échange français, dont les statistiques publiques ne montrent qu’une faible augmentation du trafic. Même chose chez son équivalent allemand, le DE-CIX. (Mais rappelez-vous qu’à d’autres endroits, la situation peut être plus sérieuse.) Les discussions sur les forums d’opérateurs réseau, comme le FRnog en France, ne montrent pas d’inquiétude particulière.
Le trafic total au point d’échange France-IX depuis un mois. Le début du confinement, le 17 mars, se voit à peine.
Le trafic des clients ADSL du FAI (Fournisseur d’Accès Internet) FDN depuis un mois. L’effet du confinement est visible dans les derniers jours, à droite, mais pas spectaculaire.
Mais pourquoi est-ce qu’il n’y a pas d’augmentation massive et généralisée du trafic, alors qu’il y a beaucoup plus de gens qui travaillent depuis chez eux ? C’est en partie parce que, lorsque les gens travaillaient dans les locaux de l’entreprise, ils utilisaient déjà l’Internet. Si on consulte un site Web pour le travail, qu’on le fasse à la maison ou au bureau ne change pas grand-chose. De même, les vidéo-conférences (et même audio), très consommatrices de capacité du réseau, se faisaient déjà au bureau (si vous comprenez l’anglais, je vous recommande cette hilarante vidéo sur la réalité des « conf calls »). Il y a donc accroissement du trafic total (mais difficile à quantifier, pour les raisons exposées plus haut), mais pas forcément dans les proportions qu’on pourrait croire. Il y a les enfants qui consomment de la capacité réseau à la maison dans la journée, ce qu’ils ne faisaient pas à l’école, davantage de réunions à distance, etc., mais il n’y a pas de bouleversement complet des usages.
Votre usage de l’Internet est-il essentiel ?
Mais qu’est-ce qui fait que des gens importants, comme Thierry Breton, cité plus haut, tapent sur Netflix, YouTube et les autres, et exigent qu’on limite leur activité ? Cela n’a rien à voir avec la surcharge des réseaux et tout à voir avec la question de la neutralité de l’Internet. La neutralité des réseaux, c’est l’idée que l’opérateur réseau ne doit pas décider à la place des utilisateurs ce qui est bon pour eux. Quand vous prenez l’autoroute, la société d’autoroute ne vous demande pas si vous partez en week-end, ou bien s’il s’agit d’un déplacement professionnel, et n’essaie pas d’évaluer si ce déplacement est justifié. Cela doit être pareil pour l’Internet. Or, certains opérateurs de télécommunications rejettent ce principe de neutralité depuis longtemps, et font régulièrement du lobbying pour demander la possibilité de trier, d’évaluer ce qu’ils considèrent comme important et le reste. Leur cible favorite, ce sont justement les plate-formes comme Netflix, dont ils demandent qu’elles les paient pour être accessible par leur réseau. Et certaines autorités politiques sont d’accord, regrettant le bon vieux temps de la chaîne de télévision unique, et voulant un Internet qu’ils contrôlent. Le confinement est juste une occasion de relancer cette campagne.
Mais, penserez-vous peut-être, on ne peut pas nier qu’il y a des usages plus importants que d’autres, non ? Une vidéo-conférence professionnelle est certainement plus utile que de regarder une série sur Netflix, n’est-ce pas ? D’abord, ce n’est pas toujours vrai : de nombreuses entreprises, et, au sein d’une entreprise, de nombreux employés font un travail sans utilité sociale (et parfois négatif pour la société) : ce n’est pas parce qu’une activité rapporte de l’argent qu’elle est forcément bénéfique pour la collectivité ! Vous n’êtes pas d’accord avec moi ? Je vous comprends, car, justement, la raison principale pour laquelle la neutralité de l’Internet est quelque chose de crucial est que les gens ne sont pas d’accord sur ce qui est essentiel. La neutralité du réseau est une forme de laïcité : comme on n’aura pas de consensus, au moins, il faut trouver un mécanisme qui permette de respecter les choix. Je pense que les Jeux Olympiques sont un scandaleux gaspillage, et un exemple typique des horreurs du sport-spectacle. Un autre citoyen n’est pas d’accord et il trouve que les séries que je regarde sur Netflix sont idiotes. La neutralité du réseau, c’est reconnaître qu’on ne tranchera jamais entre ces deux points de vue. Car, si on abandonnait la neutralité, on aurait un problème encore plus difficile : qui va décider ? Qui va choisir de brider ou pas les matches de foot ? Les vidéos de chatons ? La vidéo-conférence ?
D’autant plus que l’Internet est complexe, et qu’on ne peut pas demander à un routeur de décider si tel ou tel contenu est essentiel. J’ai vu plusieurs personnes citer YouTube comme exemple de service non-essentiel. Or, contrairement à Netflix ou PornHub, YouTube ne sert pas qu’au divertissement, ce service héberge de nombreuses vidéos éducatives ou de formation, les enseignants indiquent des vidéos YouTube à leurs élèves, des salariés se forment sur YouTube. Pas question donc de brider systématiquement cette plate-forme. (Il faut aussi dire que le maintien d’un bon moral est crucial, quand on est confiné à la maison, et que les services dits « de divertissement » sont cruciaux. Si vous me dites que non, je vous propose d’être confiné dans une petite HLM avec quatre enfants de 3 à 14 ans.)
À l’heure où j’écris, Netflix et YouTube ont annoncé une dégradation délibérée de leur service, pour répondre aux injonctions des autorités. On a vu que les réseaux sont loin de la saturation et cette mesure ne servira donc à rien. Je pense que ces plate-formes essaient simplement de limiter les dommages en termes d’image liés à l’actuelle campagne de presse contre la neutralité.
Conclusion
J’ai dit que l’Internet n’était pas du tout proche d’un écroulement ou d’une saturation. Mais cela ne veut pas dire qu’on puisse gaspiller bêtement cette utile ressource. Je vais donc donner deux conseils pratiques pour limiter le débit sur le réseau :
Utilisez un bloqueur de publicités, afin de limiter le chargement de ressources inutiles,
Préférez l’audio-conférence à la vidéo-conférence, et les outils textuels (messagerie instantanée, courrier électronique, et autres outils de travail en groupe) à l’audio-conférence.
Que va-t-il se passer dans les jours à venir ? C’est évidemment impossible à dire. Rappelons-nous simplement que, pour l’instant, rien n’indique une catastrophe à venir, et il n’y a donc aucune raison valable de prendre des mesures autoritaires pour brider tel ou tel service.
Quelques lectures supplémentaires sur ce sujet :
Un exemple d’un article anxiogène (notez que, comme souvent dans la presse, le titre est beaucoup plus sensationnaliste que l’article, finalement assez mesuré),
Un point de vue d’un opérateur (tous les opérateurs Internet ne reprennent pas le récit des gros qui monopolisent les médias, notamment, il pointe bien l’aspect essentiellement « business » de l’affaire),
Si vous vous intéressez aux aspects opérationnels de l’administration de réseaux en période de crise, je vous recommande l’exposé d’un expert, Job Snijders (en anglais) ; vous y apprendrez pourquoi le poids (en kilos) d’un routeur compte et pourquoi les navires câbliers vont être, encore plus que d’habitude, une ressource critique,
Laurent Chemla propose : exigeons des GAFAM l’interopérabilité
« Il est évidemment plus qu’urgent de réguler les GAFAM pour leur imposer l’interopérabilité. » écrit Laurent Chemla. Diable, il n’y va pas de main morte, le « précurseur dans le domaine d’Internet » selon sa page Wikipédia.
Nous reproduisons ici avec son accord l’article qu’il vient de publier sur son blog parce qu’il nous paraît tout à fait intéressant et qu’il est susceptible de provoquer le débat : d’aucuns trouveront sa proposition nécessaire pour franchir une étape dans la lutte contre des Léviathans numériques et le consentement à la captivité. D’autres estimeront peut-être que sa conception a de bien faibles chances de se concrétiser : est-il encore temps de réguler les Gafam ?
Nous souhaitons que s’ouvre ici (ou sur son blog bien sûr) la discussion. Comme toujours sur le Framablog, les commentaires sont ouverts mais modérés.
Interopérabilitay
« Interopérabilité » : ce mot m’ennuie. Il est moche, et beaucoup trop long.
Pourtant il est la source même d’Internet. Quasiment sa définition, au moins sémantique puisqu’il s’agit de faire dialoguer entre eux des systèmes d’information d’origines variées mais partageant au sein d’un unique réseau de réseaux la même « lingua franca » : TCP/IP et sa cohorte de services (ftp, http, smtp et tant d’autres) définis par des standards communs. Des machines « interopérables », donc.
Faisons avec.
L’interopérabilité, donc, est ce qui a fait le succès d’Internet, et du Web. Vous pouvez vous connecter sur n’importe quel site Web, installé sur n’importe quel serveur, quelle que soit sa marque et son système d’exploitation, depuis votre propre ordinateur, quelle que soit sa marque, son système d’exploitation, et le navigateur installé dessus.
Avant ça existaient les silos. Compuserve, AOL, The Microsoft Network en étaient les derniers représentants, dinosaures communautaires enterrés par la comète Internet. Leur volonté d’enfermer le public dans des espaces fermés, contrôlés, proposant tant bien que mal tous les services à la fois, fut ridiculisée par la décentralisation du Net.
Ici vous ne pouviez échanger qu’avec les clients du même réseau, utilisant le même outil imposé par le vendeur (« pour votre sécurité »), là vous pouviez choisir votre logiciel de mail, et écrire à n’importe qui n’importe où. Interopérabilité.
Ici vous pouviez publier vos humeurs, dans un format limité et imposé par la plateforme (« pour votre sécurité »), là vous pouviez installer n’importe quel « serveur web » de votre choix et y publier librement des pages accessibles depuis n’importe quel navigateur. Interopérabilité.
Bref. Le choix était évident, Internet a gagné.
Il a gagné, et puis… Et puis, selon un schéma désormais compris de tous, le modèle économique « gratuité contre publicité » a envahi le Web, en créant – une acquisition après l’autre, un accaparement de nos données après l’autre – de nouveaux géants qui, peu à peu, se sont refermés sur eux-mêmes (« pour votre sécurité »).
Il fut un temps où vous pouviez écrire à un utilisateur de Facebook Messenger depuis n’importe quel client, hors Facebook, respectant le standard (en l’occurrence l’API) défini par Facebook. Et puis Facebook a arrêté cette fonctionnalité. Il fut un temps où vous pouviez développer votre propre client Twitter, qui affichait ses timelines avec d’autres règles que celles de l’application officielle, pourvu qu’il utilise le standard (encore une API) défini par Twitter. Et puis Twitter a limité cette fonctionnalité. De nos jours, il devient même difficile d’envoyer un simple email à un utilisateur de Gmail si l’on utilise pas soi-même Gmail, tant Google impose de nouvelles règles (« pour votre sécurité ») à ce qui était, avant, un standard universel.
On comprend bien les raisons de cette re-centralisation : tout utilisateur désormais captif devra passer davantage de temps devant les publicités, imposées pour pouvoir utiliser tel ou tel service fermé. Et il devra – pour continuer d’utiliser ce service – fournir toujours davantage de ses données personnelles permettant d’affiner son profil et de vendre plus cher les espaces publicitaires. Renforçant ainsi toujours plus les trésoreries et le pouvoir de ces géants centralisateurs, qui ainsi peuvent aisément acquérir ou asphyxier tout nouveau wanabee concurrent, et ainsi de suite.
C’est un cercle vertueux (pour les GAFAM) et vicieux (pour nos vies privées et nos démocraties), mais c’est surtout un cercle « normal » : dès lors que rien n’impose l’interopérabilité, alors – pour peu que vous soyez devenu assez gros pour vous en passer – vous n’avez plus aucun intérêt à donner accès à d’autres aux données qui vous ont fait roi. Et vous abandonnez alors le modèle qui a permis votre existence au profit d’un modèle qui permet votre croissance. Infinie.
Imaginez, par exemple, qu’à l’époque des cassettes vidéo (respectant le standard VHS) un fabricant de magnétoscopes ait dominé à ce point le marché qu’on ait pu dire qu’il n’en existait virtuellement pas d’autres : il aurait évidemment modifié ce standard à son profit, en interdisant par exemple l’utilisation de cassettes d’autres marques que la sienne (« pour votre sécurité »), de manière à garantir dans le temps sa domination. C’est un comportement « normal », dans un monde libéral et capitaliste. Et c’est pour limiter ce comportement « normal » que les sociétés inventent des régulations (standards imposés, règles de concurrence, lois et règlements).
Et il est évidemment plus qu’urgent de réguler les GAFAM pour leur imposer l’interopérabilité.
Nous devons pouvoir, de nouveau, écrire depuis n’importe quel logiciel de messagerie à un utilisateur de Facebook Messenger, pourvu qu’on respecte le standard défini par Facebook, comme nous devons écrire à n’importe quel utilisateur de Signal en respectant le standard de chiffrement de Signal. Il n’est pas question d’imposer à Signal (ou à Facebook) un autre standard que celui qu’il a choisi (ce qui empêcherait toute innovation), pourvu que le standard choisi soit public, et libre d’utilisation. Mais il est question de contraindre Facebook à (ré)ouvrir ses API pour permettre aux utilisateurs d’autres services d’interagir de nouveau avec ses propres utilisateurs.
Au passage, ce point soulève une problématique incidente : l’identité. Si je peux écrire à un utilisateur de Messenger, celui-ci doit pouvoir me répondre depuis Messenger. Or Messenger ne permet d’écrire qu’aux autres utilisateurs de Messenger, identifiés par Facebook selon ses propres critères qu’il n’est pas question de lui imposer (il a le droit de ne vouloir admettre que des utilisateurs affichant leur « identité réelle », par exemple : ce choix est le sien, comme il a le droit de limiter les fonctionnalités de Messenger pour lui interdire d’écrire à d’autres : ce choix est aussi le sien).
Il est donc cohérent d’affirmer que – pour pouvoir écrire à un utilisateur de Messenger depuis un autre outil – il faut avoir soi-même un compte Messenger. Il est donc logique de dire que pour pouvoir lire ma timeline Twitter avec l’outil de mon choix, je dois avoir un compte Twitter. Il est donc évident que pour accéder à mon historique d’achat Amazon, je dois avoir un compte Amazon, etc.
capture d’écran, discussion avec L. Chemla sur Twitter. cliquez sur cette vignette pour agrandir l’image
L’obligation d’avoir une identité reconnue par le service auquel on accède, c’est sans doute le prix à payer pour l’interopérabilité, dans ce cas (et – au passage – c’est parce que la Quadrature du Net a décidé d’ignorer cette évidence que j’ai choisi de quitter l’association).
Ce qui ne doit évidemment pas nous obliger à utiliser Messenger, Amazon ou Twitter pour accéder à ces comptes: l’interopérabilité doit d’accéder à nos contacts et à nos données depuis l’outil de notre choix, grâce à l’ouverture obligatoire des API, pourvu qu’on dispose d’une identité respectant les standards du service qui stocke ces données.
On pourrait résumer ce nouveau type de régulation avec cette phrase simple :
« si ce sont MES données, alors je dois pouvoir y accéder avec l’outil de MON choix ».
Je dois pouvoir lire ma timeline Twitter depuis l’outil de mon choix (et y publier, si évidemment j’y ai un compte, pour que les autres utilisateurs de Twitter puissent s’y abonner).
Je dois pouvoir consulter mon historique d’achats chez Amazon avec l’outil de mon choix.
Je dois pouvoir écrire à (et lire les réponses de) mes contacts Facebook avec l’outil de mon choix.
Il y aura, évidemment, des résistances.
On nous dira (« pour votre sécurité ») que c’est dangereux, parce que nos données personnelles ne seront plus aussi bien protégées, dispersées parmi tellement de services décentralisés et piratables. Mais je préfère qu’une partie de mes données soit moins bien protégée (ce qui reste à démontrer) plutôt que de savoir qu’une entreprise privée puisse vendre (ou perdre) la totalité de ce qui est MA vie.
On nous dira que c’est « excessivement agressif pour le modèle économique des grandes plateformes », alors qu’évidemment c’est justement le modèle économique des grandes plateformes qui est excessivement agressif pour nos vies privées et nos démocraties, d’une part, et que d’autre part l’interopérabilité ne modifie en rien ce modèle économique : dès lors qu’elles stockent toujours une partie de nos données elles restent (hélas) en capacité de les vendre et/ou de les utiliser pour « éduquer » leurs IA. Tout au plus constateront-elles un manque-à-gagner comptable, mais ne gagnent-elles pas déjà largement assez ?
À ce jour, l’interopérabilité s’impose comme la seule solution réaliste pour limiter le pouvoir de nuisance de ces géants, et pour rétablir un peu de concurrence et de décentralisation dans un réseau qui, sinon, n’a plus d’autre raison d’être autre chose qu’un simple moyen d’accéder à ces nouveaux silos (qu’ils devraient donc financer, eux, plutôt que les factures de nos FAI).
À ce jour, l’ARCEP, la Quadrature du Net (même mal), l’EFF, le Sénat, et même l’Europe (Margrethe Vestager s’est elle-même déclarée en faveur de cette idée) se sont déclarés pour une obligation d’intéropérabilité. C’est la suite logique (et fonctionnelle) du RGPD.
Qu’est-ce qu’on attend ?
Édit. de Laurent suite à la publication de l’article sur son blog
Suite à ce billet des discussions sur Twitter et Mastodon, indépendamment, m’ont amené à préciser ceci : prenons par exemple mamot.fr (l’instance Mastodon de la Quadrature) et gab.ai (l’instance Mastodon de la fachosphère). Mamot.fr, comme nombre d’autres instances, a refusé de se fédérer avec Gab. C’est son droit. En conséquence, les utilisateurs de Gab ne peuvent pas poster sur Mamot, et inversement.
Pour autant, les deux sont bel et bien interopérables, et pour cause : elles utilisent le même logiciel. Gab pourrait parfaitement développer un bout de code pour permettre à ses utilisateurs de publier sur Mamot, pour peu qu’ils s’y soient identifiés (via une OAuth, pour les techniciens) prouvant ainsi qu’ils en acceptent les CGU.
Ce qu’elles ne sont pas, c’est interconnectées : il n’est pas possible de publier sur l’une en s’identifiant sur l’autre, et inversement.
Je crois qu’au fond, les tenants de l’idée qu’on devrait pouvoir publier n’importe quoi n’importe où, sans identification supplémentaire, confondent largement ces deux notions d’interconnexion et d’interopérabilité. Et c’est fort dommage, parce que ça brouille le message de tous.
C’est quoi, l’interopérabilité, et pourquoi est-ce beau et bien ?
Protocole, HTTP, interopérabilité, ça vous parle ? Et normes, spécifications, RFC, ça va toujours ? Si vous avez besoin d’y voir un peu plus clair, l’article ci-dessous est un morceau de choix rédigé par Stéphane Bortzmeyer qui s’est efforcé de rendre accessibles ces notions fondamentales.
Protocoles
Le 21 mai 2019, soixante-neuf organisations, dont Framasoft, ont signé un appel à ce que soit imposé, éventuellement par la loi, un minimum d’interopérabilité pour les gros acteurs commerciaux du Web.
« Interopérabilité » est un joli mot, mais qui ne fait pas forcément partie du vocabulaire de tout le monde, et qui mérite donc d’être expliqué. On va donc parler d’interopérabilité, de protocoles, d’interfaces, de normes, et j’espère réussir à le faire tout en restant compréhensible (si vous êtes informaticien·ne professionnel·le, vous savez déjà tout cela ; mais l’appel des 69 organisations concerne tout le monde).
Le Web, ou en fait tout l’Internet, repose sur des protocoles de communication. Un protocole, c’est un ensemble de règles qu’il faut suivre si on veut communiquer. Le terme vient de la communication humaine, par exemple, lorsqu’on rencontre quelqu’un, on se serre la main, ou bien on se présente si l’autre ne vous connaît pas, etc. Chez les humains, le protocole n’est pas rigide (sauf en cas de réception par la reine d’Angleterre dans son palais, mais cela doit être rare chez les lectrices et lecteurs du Framablog). Si la personne avec qui vous communiquez ne respecte pas exactement le protocole, la communication peut tout de même avoir lieu, quitte à se dire que cette personne est bien impolie. Mais les logiciels ne fonctionnent pas comme des humains. Contrairement aux humains, ils n’ont pas de souplesse, les règles doivent être suivies exactement. Sur un réseau comme l’Internet, pour que deux logiciels puissent communiquer, chacun doit donc suivre exactement les mêmes règles, et c’est l’ensemble de ces règles qui fait un protocole.
Un exemple concret ? Sur le Web, pour que votre navigateur puisse afficher la page web désirée, il doit demander à un serveur web un ou plusieurs fichiers. La demande se fait obligatoirement en envoyant au serveur le mot GET (« donne », en anglais) suivi du nom du fichier, suivi du mot « HTTP/1.1 ». Si un navigateur web s’avisait d’envoyer le nom du fichier avant le mot GET, le serveur ne comprendrait rien, et renverrait plutôt un message d’erreur. En parlant d’erreurs, vous avez peut-être déjà rencontré le nombre 404 qui est simplement le code d’erreur qu’utilisent les logiciels qui parlent HTTP pour signaler que la page demandée n’existe pas. Ces codes numériques, conçus pour être utilisés entre logiciels, ont l’avantage sur les textes de ne pas être ambigus, et de ne pas dépendre d’une langue humaine particulière. Cet exemple décrit une toute petite partie du protocole nommé HTTP (pour Hypertext Transfer Protocol) qui est le plus utilisé sur le Web.
Il existe des protocoles bien plus complexes. Le point important est que, derrière votre écran, les logiciels communiquent entre eux en utilisant ces protocoles. Certains servent directement aux logiciels que vous utilisez (comme HTTP, qui permet à votre navigateur Web de communiquer avec le serveur qui détient les pages désirées), d’autres protocoles relèvent de l’infrastructure logicielle de l’Internet ; vos logiciels n’interagissent pas directement avec eux, mais ils sont indispensables.
Le protocole, ces règles de communication, sont indispensables dans un réseau comme l’Internet. Sans protocole, deux logiciels ne pourraient tout simplement pas communiquer, même si les câbles sont bien en place et les machines allumées. Sans protocole, les logiciels seraient dans la situation de deux humains, un Français ne parlant que français, et un Japonais ne parlant que japonais. Même si chacun a un téléphone et connaît le numéro de l’autre, aucune vraie communication ne pourra prendre place. Tout l’Internet repose donc sur cette notion de protocole.
Le protocole permet l’interopérabilité. L’interopérabilité est la capacité à communiquer de deux logiciels différents, issus d’équipes de développement différentes. Si une université bolivienne peut échanger avec une entreprise indienne, c’est parce que toutes les deux utilisent des protocoles communs.
Seuls les protocoles ont besoin d’être communs : l’Internet n’oblige pas à utiliser les mêmes logiciels, ni à ce que les logiciels aient la même interface avec l’utilisateur. Si je prends l’exemple de deux logiciels qui parlent le protocole HTTP, le navigateur Mozilla Firefox (que vous êtes peut-être en train d’utiliser pour lire cet article) et le programme curl (utilisé surtout par les informaticiens pour des opérations techniques), ces deux logiciels ont des usages très différents, des interfaces avec l’utilisateur reposant sur des principes opposés, mais tous les deux parlent le même protocole HTTP. Le protocole, c’est ce qu’on parle avec les autres logiciels (l’interface avec l’utilisateur étant, elle, pour les humain·e·s.).
La distinction entre protocole et logiciel est cruciale. Si j’utilise le logiciel A parce que je le préfère et vous le logiciel B, tant que les deux logiciels parlent le même protocole, aucun problème, ce sera juste un choix individuel. Malgré leurs différences, notamment d’interface utilisateur, les deux logiciels pourront communiquer. Si, en revanche, chaque logiciel vient avec son propre protocole, il n’y aura pas de communication, comme dans l’exemple du Français et du Japonais plus haut.
Babel
Alors, est-ce que tous les logiciels utilisent des protocoles communs, permettant à tout le monde de communiquer avec bonheur ? Non, et ce n’est d’ailleurs pas obligatoire. L’Internet est un réseau à « permission facultative ». Contrairement aux anciennes tentatives de réseaux informatiques qui étaient contrôlés par les opérateurs téléphoniques, et qui décidaient de quels protocoles et quelles applications tourneraient sur leurs réseaux, sur l’Internet, vous pouvez inventer votre propre protocole, écrire les logiciels qui le parlent et les diffuser en espérant avoir du succès. C’est d’ailleurs ainsi qu’a été inventé le Web : Tim Berners-Lee (et Robert Cailliau) n’ont pas eu à demander la permission de qui que ce soit. Ils ont défini le protocole HTTP, ont écrit les applications et leur invention a connu le succès que l’on sait.
Cette liberté d’innovation sans permission est donc une bonne chose. Mais elle a aussi des inconvénients. Si chaque développeur ou développeuse d’applications invente son propre protocole, il n’y aura plus de communication ou, plus précisément, il n’y aura plus d’interopérabilité. Chaque utilisatrice et chaque utilisateur ne pourra plus communiquer qu’avec les gens ayant choisi le même logiciel. Certains services sur l’Internet bénéficient d’une bonne interopérabilité, le courrier électronique, par exemple. D’autres sont au contraire composés d’un ensemble de silos fermés, ne communiquant pas entre eux. C’est par exemple le cas des messageries instantanées. Chaque application a son propre protocole, les personnes utilisant WhatsApp ne peuvent pas échanger avec celles utilisant Telegram, qui ne peuvent pas communiquer avec celles qui préfèrent Signal ou Riot. Alors que l’Internet était conçu pour faciliter la communication, ces silos enferment au contraire leurs utilisateurs et utilisatrices dans un espace clos.
La situation est la même pour les réseaux sociaux commerciaux comme Facebook. Vous ne pouvez communiquer qu’avec les gens qui sont eux-mêmes sur Facebook. Les pratiques de la société qui gère ce réseau sont déplorables, par exemple en matière de captation et d’utilisation des données personnelles mais, quand on suggère aux personnes qui utilisent Facebook de quitter ce silo, la réponse la plus courante est « je ne peux pas, tou·te·s mes ami·e·s y sont, et je ne pourrais plus communiquer avec eux et elles si je partais ». Cet exemple illustre très bien les dangers des protocoles liés à une entreprise et, au contraire, l’importance de l’interopérabilité.
Mais pourquoi existe-t-il plusieurs protocoles pour un même service ? Il y a différentes raisons. Certaines sont d’ordre technique. Je ne les développerai pas ici, ce n’est pas un article technique, mais les protocoles ne sont pas tous équivalents, il y a des raisons techniques objectives qui peuvent faire choisir un protocole plutôt qu’un autre. Et puis deux personnes différentes peuvent estimer qu’en fait deux services ne sont pas réellement identiques et méritent donc des protocoles séparés, même si tout le monde n’est pas d’accord.
Mais il peut aussi y avoir des raisons commerciales : l’entreprise en position dominante n’a aucune envie que des acteurs plus petits la concurrencent, et ne souhaite pas permettre à des nouveaux entrants d’arriver. Elle a donc une forte motivation à n’utiliser qu’un protocole qui lui est propre, que personne d’autre ne connaît.
Enfin, il peut aussi y avoir des raisons plus psychologiques, comme la conviction chez l·e·a créat·eur·rice d’un protocole que son protocole est bien meilleur que les autres.
Un exemple d’un succès récent en termes d’adoption d’un nouveau protocole est donné par le fédivers. Ce terme, contraction de « fédération » et « univers » (et parfois écrit « fédiverse » par anglicisme) regroupe tous les serveurs qui échangent entre eux par le protocole ActivityPub, que l’appel des soixante-neuf organisations mentionne comme exemple. ActivityPub permet d’échanger des messages très divers. Les logiciels Mastodon et Pleroma se servent d’ActivityPub pour envoyer de courts textes, ce qu’on nomme du micro-blogging (ce que fait Twitter). PeerTube utilise ActivityPub pour permettre de voir les nouvelles vidéos et les commenter. WriteFreely fait de même avec les textes que ce logiciel de blog permet de rédiger et diffuser. Et, demain, Mobilizon utilisera ActivityPub pour les informations sur les événements qu’il permettra d’organiser. Il s’agit d’un nouvel exemple de la distinction entre protocole et logiciel. Bien que beaucoup de gens appellent le fédivers « Mastodon », c’est inexact. Mastodon n’est qu’un des logiciels qui permettent l’accès au fédivers.
Le terme d’ActivityPub n’est d’ailleurs pas idéal. Il y a en fait un ensemble de protocoles qui sont nécessaires pour communiquer au sein du fédivers. ActivityPub n’est que l’un d’entre eux, mais il a un peu donné son nom à l’ensemble.
Tous les logiciels de la mouvance des « réseaux sociaux décentralisés » n’utilisent pas ActivityPub. Par exemple, Diaspora ne s’en sert pas et n’est donc pas interopérable avec les autres.
Appel
Revenons maintenant l’appel cité au début, Que demande-t-il ? Cet appel réclame que l’interopérabilité soit imposée aux GAFA, ces grosses entreprises capitalistes qui sont en position dominante dans la communication. Tous sont des silos fermés. Aucun moyen de commenter une vidéo YouTube si on a un compte PeerTube, de suivre les messages sur Twitter ou Facebook si on est sur le fédivers. Ces GAFA ne changeront pas spontanément : il faudra les y forcer.
Il ne s’agit que de la communication externe. Cet appel est modéré dans le sens où il ne demande pas aux GAFA de changer leur interface utilisateur, ni leur organisation interne, ni leurs algorithmes de sélection des messages, ni leurs pratiques en matière de gestion des données personnelles. Il s’agit uniquement d’obtenir qu’ils permettent l’interopérabilité avec des services concurrents, de façon à permettre une réelle liberté de choix par les utilisateurs. Un tel ajout est simple à implémenter pour ces entreprises commerciales, qui disposent de fonds abondants et de nombreu·ses-x programmeur·e·s compétent·e·s. Et il « ouvrirait » le champ des possibles. Il s’agit donc de défendre les intérêts des utilisateurs et utilisatrices. (Alors que le gouvernement, dans ses commentaires, n’a cité que les intérêts des GAFA, comme si ceux-ci étaient des espèces menacées qu’il fallait défendre.)
Qui commande ?
Mais au fait, qui décide des protocoles, qui les crée ? Il n’y a pas de réponse simple à cette question. Il existe plein de protocoles différents et leurs origines sont variées. Parfois, ils sont rédigés, dans un texte qui décrit exactement ce que doivent faire les deux parties. C’est ce que l’on nomme une spécification. Mais parfois il n’y a pas vraiment de spécification, juste quelques vagues idées et un programme qui utilise ce protocole. Ainsi, le protocole BitTorrent, très utilisé pour l’échange de fichiers, et pour lequel il existe une très bonne interopérabilité, avec de nombreux logiciels, n’a pas fait l’objet d’une spécification complète. Rien n’y oblige développeurs et développeuses : l’Internet est « à permission facultative ». Dans de tels cas, celles et ceux qui voudraient créer un programme interopérable devront lire le code source (les instructions écrites par le ou la programmeur·e) ou analyser le trafic qui circule, pour essayer d’en déduire en quoi consiste le protocole (ce qu’on nomme la rétro-ingénierie). C’est évidemment plus long et plus difficile et il est donc très souhaitable, pour l’interopérabilité, qu’il existe une spécification écrite et correcte (il s’agit d’un exercice difficile, ce qui explique que certains protocoles n’en disposent pas).
Parfois, la spécification est adoptée formellement par un organisme dont le rôle est de développer et d’approuver des spécifications. C’est ce qu’on nomme la normalisation. Une spécification ainsi approuvée est une norme. L’intérêt d’une norme par rapport à une spécification ordinaire est qu’elle reflète a priori un consensus assez large d’une partie des acteurs, ce n’est plus un acte unilatéral. Les normes sont donc une bonne chose mais, rien n’étant parfait, leur développement est parfois laborieux et lent.
Toutes les normes ne se valent pas. Certaines sont publiquement disponibles (comme les normes importantes de l’infrastructure de l’Internet, les RFC – Request For Comments), d’autres réservées à ceux qui paient, ou à ceux qui sont membres d’un club fermé. Certaines normes sont développées de manière publique, où tout le monde a accès aux informations, d’autres sont créées derrière des portes soigneusement closes. Lorsque la norme est développée par une organisation ouverte à tous et toutes, selon des procédures publiques, et que le résultat est publiquement disponible, on parle souvent de normes ouvertes. Et, bien sûr, ces normes ouvertes sont préférables pour l’interopérabilité.
L’une des organisations de normalisation ouverte les plus connues est l’IETF (Internet Engineering Task Force, qui produit notamment la majorité des RFC). L’IETF a développé et gère la norme décrivant le protocole HTTP, le premier cité dans cet article. Mais d’autres organisations de normalisation existent comme le W3C (World-Wide Web Consortium) qui est notamment responsable de la norme ActivityPub.
Par exemple, pour le cas des messageries instantanées que j’avais citées, il y a bien une norme, portant le doux nom de XMPP (Extensible Messaging and Presence Protocol). Google l’utilisait, puis l’a abandonnée, jouant plutôt le jeu de la fermeture.
Difficultés
L’interopérabilité n’est évidemment pas une solution magique à tous les problèmes. On l’a dit, l’appel des soixante-neuf organisations est très modéré puisqu’il demande seulement une ouverture à des tiers. Si cette demande se traduisait par une loi obligeant à cette interopérabilité, tout ne serait pas résolu.
D’abord, il existe beaucoup de moyens pour respecter la lettre d’un protocole tout en violant son esprit. On le voit pour le courrier électronique où Gmail, en position dominante, impose régulièrement de nouvelles exigences aux serveurs de messagerie avec lesquels il daigne communiquer. Le courrier électronique repose, contrairement à la messagerie instantanée, sur des normes ouvertes, mais on peut respecter ces normes tout en ajoutant des règles. Ce bras de fer vise à empêcher les serveurs indépendants de communiquer avec Gmail. Si une loi suivant les préconisations de l’appel était adoptée, nul doute que les GAFA tenteraient ce genre de jeu, et qu’il faudrait un mécanisme de suivi de l’application de la loi.
Plus subtil, l’entreprise qui voudrait « tricher » avec les obligations d’interopérabilité peut aussi prétendre vouloir « améliorer » le protocole. On ajoute deux ou trois choses qui n’étaient pas dans la norme et on exerce alors une pression sur les autres organisations pour qu’elles aussi ajoutent ces fonctions. C’est un exercice que les navigateurs web ont beaucoup pratiqué, pour réduire la concurrence.
Jouer avec les normes est d’autant plus facile que certaines normes sont mal écrites, laissant trop de choses dans le vague (et c’est justement le cas d’ActivityPub). Écrire une norme est un exercice difficile. Si on laisse beaucoup de choix aux programmeuses et programmeurs qui créeront les logiciels, il y a des risques de casser l’interopérabilité, suite à des choix trop différents. Mais si on contraint ces programmeuses et programmeurs, en imposant des règles très précises pour tous les détails, on empêche les logiciels d’évoluer en réponse aux changements de l’Internet ou des usages. La normalisation reste donc un art difficile, pour lequel on n’a pas de méthode parfaite.
Conclusion
Voilà, désolé d’avoir été long, mais les concepts de protocole et d’interopérabilité sont peu enseignés, alors qu’ils sont cruciaux pour le fonctionnement de l’Internet et surtout pour la liberté des citoyen·ne·s qui l’utilisent. J’espère les avoir expliqués clairement, et vous avoir convaincu⋅e de l’importance de l’interopérabilité. Pensez à soutenir l’appel des soixante-neuf organisations !
Après
Et si vous voulez d’autres informations sur ce sujet, il y a :
Et si les géants de la technologie numérique étaient concurrencés et peut-être remplacés par les nains des technologies modestes et respectueuses des êtres humains ?
Telle est l’utopie qu’expose Aral Balkan ci-dessous. Faut-il préciser que chez Framasoft, nous avons l’impression d’être en phase avec cette démarche et de cocher déjà des cases qui font de nous ce qu’Aral appelle une Small Tech (littéralement : les petites technologies) par opposition aux Big Tech, autrement dit les GAFAM et leurs successeurs déjà en embuscade pour leur disputer les positions hégémoniques.
Les géants du numérique, avec leurs « licornes » à plusieurs milliards de dollars, nous ont confisqué le potentiel d’Internet. Alimentée par la très courte vue et la rapacité du capital-risque et des start-ups, la vision utopique d’une ressource commune décentralisée et démocratique s’est transformée en l’autocratie dystopique des panopticons de la Silicon Valley que nous appelons le capitalisme de surveillance. Cette mutation menace non seulement nos démocraties, mais aussi l’intégrité même de notre personne à l’ère du numérique et des réseaux1.
Alors que la conception éthique décrit sans ambiguïté les critères et les caractéristiques des alternatives éthiques au capitalisme de surveillance, c’est l’éthique elle-même qui est annexée par les Big Tech dans des opérations de relations publiques qui détournent l’attention des questions systémiques centrales2 pour mettre sous les projecteurs des symptômes superficiels3.
Nous avons besoin d’un antidote au capitalisme de surveillance qui soit tellement contradictoire avec les intérêts des Big Tech qu’il ne puisse être récupéré par eux. Il doit avoir des caractéristiques et des objectifs clairs et simples impossibles à mal interpréter. Et il doit fournir une alternative viable et pratique à la mainmise de la Silicon Valley sur les technologies et la société en général.
Cet antidote, c’est la Small Tech.
Small Tech
elle est conçue par des humains pour des humains 4 ;
est la propriété des individus qui la contrôlent, et non des entreprises ou des gouvernements ;
respecte, protège et renforce l’intégrité de la personne humaine, des droits humains, de la justice sociale et de la démocratie à l’ère du numérique en réseau ;
encourage une organisation politique non-hiérarchisée et où les décisions sont prises à l’échelle humaine ;
alimente un bien commun sain ;
est soutenable ;
sera un jour financée par les communs, pour le bien commun.
Nous avons un système dans lequel 99.99999% des investissements financent les entreprises qui reposent sur la surveillance et se donnent pour mission de croître de façon exponentielle en violant la vie privée de la population en général [retour]
« Attention » et « addiction ». S’il est vrai que les capitalistes de la surveillance veulent attirer notre attention et nous rendre dépendants à leurs produits, ils ne le font pas comme une fin en soi, mais parce que plus nous utilisons leurs produits, plus ils peuvent nous exploiter pour nos données. Des entreprises comme Google et Facebook sont des fermes industrielles pour les êtres humains. Leurs produits sont les machines agricoles. Ils doivent fournir une façade brillante pour garder notre attention et nous rendre dépendants afin que nous, le bétail, puissions volontairement nous autoriser à être exploités. Ces institutions ne peuvent être réformées. Les Big Tech ne peuvent être réglementées que de la même manière que la Big Tobacco pour réduire ses méfaits sur la société. Nous pouvons et devrions investir dans une alternative éthique : la Small Tech. [retour]
La petite technologie établit une relation d’humain à humain par nature. Plus précisément, elle n’est pas créée par des sociétés à but lucratif pour exploiter les individus – ce qu’on appelle la technologie entreprise vers consommateur. Il ne s’agit pas non plus d’une technologie construite par des entreprises pour d’autres entreprises [retour]
Nous construisons la Small Tech principalement pour le bien commun, pas pour faire du profit. Cela ne signifie pas pour autant que nous ne tenons pas compte du système économique dans lequel nous nous trouvons actuellement enlisés ou du fait que les solutions de rechange que nous élaborons doivent être durables. Même si nous espérons qu’un jour Small Tech sera financé par les deniers publics, pour le bien commun, nous ne pouvons pas attendre que nos politiciens et nos décideurs politiques se réveillent et mettent en œuvre un tel changement social. Alors que nous devons survivre dans le capitalisme, nous pouvons vendre et faire des profits avec la Small Tech. Mais ce n’est pas notre but premier. Nos organisations se préoccupent avant tout des méthodes durables pour créer des outils qui donnent du pouvoir aux gens sans les exploiter, et non de faire du profit. Small Tech n’est pas une organisation caritative, mais une organisation à but non lucratif.[retour]
Les organisations disposant de capitaux propres sont détenues et peuvent donc être vendues. En revanche, les organisations sans capital social (par exemple, les sociétés à responsabilité limitée par garantie en Irlande et au Royaume-Uni) ne peuvent être vendues. De plus, si une organisation a du capital-risque, on peut considérer qu’elle a déjà été vendue au moment de l’investissement car, si elle n’échoue pas, elle doit se retirer (être achetée par une grande société ou par le public en général lors d’une introduction en bourse). Les investisseurs en capital-risque investissent l’argent de leurs clients dans la sortie. La sortie est la façon dont ces investisseurs font leur retour sur investissement. Nous évitons cette pilule toxique dans la Small Tech en créant des organisations sans capitaux propres qui ne peuvent être vendues. La Silicon Valley a des entreprises de jetables qu’ils appellent des startups. Nous avons des organisations durables qui travaillent pour le bien commun que nous appelons Stayups (Note de Traduction : jeu de mots avec le verbe to stay signifie « demeurer »).[retour]
La révolution ne sera pas parrainée par ceux contre qui nous nous révoltons. Small Tech rejette le parrainage par des capitalistes de la surveillance. Nous ne permettrons pas que nos efforts soient utilisés comme des relations publiques pour légitimer et blanchir le modèle d’affaires toxique des Big Tech et les aider à éviter une réglementation efficace pour mettre un frein à leurs abus et donner une chance aux alternatives éthiques de prospérer.[retour]
La vie privée, c’est avoir le droit de décider de ce que vous gardez pour vous et de ce que vous partagez avec les autres. Par conséquent, la seule définition de la protection de la vie privée qui importe est celle de la vie privée par défaut. Cela signifie que nous concevons la Small Tech de sorte que les données des gens restent sur leurs appareils. S’il y a une raison légitime pour laquelle cela n’est pas possible (par exemple, nous avons besoin d’un nœud permanent dans un système de pair à pair pour garantir l’accessibilité et la disponibilité), nous nous assurons que les données sont chiffrées de bout en bout et que l’individu qui possède l’outil possède les clés des informations privées et puisse contrôler seul qui est à chacun des « bouts » (pour éviter le spectre du Ghosting).[retour]
La configuration de base de notre technologie est le pair à pair : un système a-centré dans lequel tous les nœuds sont égaux. Les nœuds sur lesquels les individus n’ont pas de contrôle direct (p. ex., le nœud toujours actif dans le système pair à pair mentionné dans la note précédente) sont des nœuds de relais non fiables et non privilégiés qui n’ont jamais d’accès aux informations personnelles des personnes.[retour]
Afin d’assurer un bien commun sain, nous devons protéger le bien commun contre l’exploitation et de l’enfermement. La Small Tech utilise des licences copyleft pour s’assurer que si vous bénéficiez des biens communs, vous devez redonner aux biens communs. Cela empêche également les Big Tech d’embrasser et d’étendre notre travail pour finalement nous en exclure en utilisant leur vaste concentration de richesse et de pouvoir.[retour]
La Small Tech est influencé en grande partie par la richesse du travail existant des concepteurs et développeurs inspirants de la communauté JavaScript qui ont donné naissance aux communautés DAT et Scuttlebutt. Leur philosophie, qui consiste à créer des composants pragmatiques, modulaires, minimalistes et à l’échelle humaine, aboutit à une technologie qui est accessible aux individus, qui peut être maintenue par eux et qui leur profite. Leur approche, qui est aussi la nôtre, repose sur la philosophie d’UNIX.[retour]
La Small Tech est conçue par des humains, pour des humains ; c’est une approche résolument non-coloniale. Elle n’est pas créée par des humains plus intelligents pour des humains plus bêtes (par exemple, par des développeurs pour des utilisateurs – nous n’utilisons pas le terme utilisateur dans Small Tech. On appelle les personnes, des personnes.) Nous élaborons nos outils aussi simplement que possible pour qu’ils puissent être compris, maintenus et améliorés par le plus grand nombre. Nous n’avons pas l’arrogance de supposer que les gens feront des efforts excessifs pour apprendre nos outils. Nous nous efforçons de les rendre intuitifs et faciles à utiliser. Nous réalisons de belles fonctionnalités par défaut et nous arrondissons les angles. N’oubliez pas : la complexité survient d’elle-même, mais la simplicité, vous devez vous efforcer de l’atteindre. Dans la Small Tech, trop intelligent est une façon de dire stupide. Comme le dit Brian Kernighan : « Le débogage est deux fois plus difficile que l’écriture du premier jet de code. Par conséquent, si vous écrivez du code aussi intelligemment que possible, vous n’êtes, par définition, pas assez intelligent pour le déboguer. » Nous nous inspirons de l’esprit de la citation de Brian et l’appliquons à tous les niveaux : financement, structure organisationnelle, conception du produit, son développement, son déploiement et au-delà.[retour]
Chrome, de navigateur internet novateur et ouvert, est devenu au fil des années un rouage essentiel de la domination d’Internet par Google. Cet article détaille les raisons pour lesquelles Chrome asphyxie le Web ouvert et pourquoi il faudrait passer sur un autre navigateur tel Vivaldi ou Firefox.
Il y a dix ans, nous avons eu besoin de Google Chrome pour libérer le Web de l’hégémonie des entreprises, et nous avons réussi à le faire pendant une courte période. Aujourd’hui, sa domination étouffe la plateforme même qu’il a autrefois sauvée des griffes de Microsoft. Et personne, à part Google, n’a besoin de ça.
Nous sommes en 2008. Microsoft a toujours une ferme emprise sur le marché des navigateurs web. Six années se sont écoulées depuis que Mozilla a sorti Firefox, un concurrent direct d’Internet Explorer. Google, l’entreprise derrière le moteur de recherche que tout le monde aimait à ce moment-là, vient d’annoncer qu’il entre dans la danse. Chrome était né.
Au bout de deux ans, Chrome représentait 15 % de l’ensemble du trafic web sur les ordinateurs fixes — pour comparer, il a fallu 6 ans à Firefox pour atteindre ce niveau. Google a réussi à fournir un navigateur rapide et judicieusement conçu qui a connu un succès immédiat parmi les utilisateurs et les développeurs Web. Les innovations et les prouesses d’ingénierie de leur produit étaient une bouffée d’air frais, et leur dévouement à l’open source la cerise sur le gâteau. Au fil des ans, Google a continué à montrer l’exemple en adoptant les standards du Web.
Avançons d’une décennie. Le paysage des navigateurs Web est très différent. Chrome est le navigateur le plus répandu de la planète, faisant de facto de Google le gardien du Web, à la fois sur mobile et sur ordinateur fixe, partout sauf dans une poignée de régions du monde. Le navigateur est préinstallé sur la plupart des téléphones Android vendus hors de Chine, et sert d’interface utilisateur pour Chrome OS, l’incursion de Google dans les systèmes d’exploitation pour ordinateurs fixe et tablettes. Ce qui a commencé comme un navigateur d’avant-garde respectant les standards est maintenant une plateforme tentaculaire qui n’épargne aucun domaine de l’informatique moderne.
Bien que le navigateur Chrome ne soit pas lui-même open source, la plupart de ses composantes internes le sont. Chromium, la portion non-propriétaire de Chrome, a été rendue open source très tôt, avec une licence laissant de larges marges de manœuvre, en signe de dévouement à la communauté du Web ouvert. En tant que navigateur riche en fonctionnalités, Chromium est devenu très populaire auprès des utilisateurs de Linux. En tant que projet open source, il a de nombreux adeptes dans l’écosystème open source, et a souvent été utilisé comme base pour d’autres navigateurs ou applications.
Tant Chrome que Chromium se basent sur Blink, le moteur de rendu qui a démarré comme un fork de WebKit en 2013, lorsque l’insatisfaction de Google grandissait envers le projet mené par Apple. Blink a continué de croître depuis lors, et va continuer de prospérer lorsque Microsoft commencera à l’utiliser pour son navigateur Edge.
La plateforme Chrome a profondément changé le Web. Et plus encore. L’adoption des technologies web dans le développement des logiciels PC a connu une augmentation sans précédent dans les 5 dernières années, avec des projets comme Github Electron, qui s’imposent sur chaque OS majeur comme les standards de facto pour des applications multiplateformes. ChromeOS, quoique toujours minoritaire comparé à Windows et MacOS, s’installe dans les esprits et gagne des parts de marché.
Chrome est, de fait, partout. Et c’est une mauvaise nouvelle
Don’t Be Evil
L’hégémonie de Chrome a un effet négatif majeur sur le Web en tant que plateforme ouverte : les développeurs boudent de plus en plus les autres navigateurs lors de leurs tests et de leurs débogages. Si cela fonctionne comme prévu sur Chrome, c’est prêt à être diffusé. Cela engendre en retour un afflux d’utilisateurs pour le navigateur puisque leurs sites web et applications favorites ne marchent plus ailleurs, rendant les développeurs moins susceptibles de passer du temps à tester sur les autres navigateurs. Un cercle vicieux qui, s’il n’est pas brisé, entraînera la disparition de la plupart des autres navigateurs et leur oubli. Et c’est exactement comme ça que vous asphyxiez le Web ouvert.
Quand il s’agit de promouvoir l’utilisation d’un unique navigateur Web, Google mène la danse. Une faible assurance de qualité et des choix de conception discutables sont juste la surface visible de l’iceberg quand on regarde les applications de Google et ses services en dehors de l’écosystème Chrome. Pour rendre les choses encore pires, le blâme retombe souvent sur les autres concurrents car ils « retarderaient l’avancée du Web ». Le Web est actuellement le terrain de jeu de Google ; soit vous faites comme ils disent, soit on vous traite de retardataire.
Sans une compétition saine et équitable, n’importe quelle plateforme ouverte régressera en une organisation dirigiste. Pour le Web, cela veut dire que ses points les plus importants — la liberté et l’accessibilité universelle — sont sapés pour chaque pour-cent de part de marché obtenu par Chrome. Rien que cela est suffisant pour s’inquiéter. Mais quand on regarde de plus près le modèle commercial de Google, la situation devient beaucoup plus effrayante.
La raison d’être de n’importe quelle entreprise est de faire du profit et de satisfaire les actionnaires. Quand la croissance soutient une bonne cause, c’est considéré comme un avantage compétitif. Dans le cas contraire, les services marketing et relations publiques sont mis au travail. Le mantra de Google, « Don’t be evil« , s’inscrivait parfaitement dans leur récit d’entreprise quand leur croissance s’accompagnait de rendre le Web davantage ouvert et accessible.
Hélas, ce n’est plus le cas.
Logos de Chrome
L’intérêt de l’entreprise a dérivé petit à petit pour transformer leur domination sur le marché des navigateurs en une croissance du chiffre d’affaires. Il se trouve que le modèle commercial de Google est la publicité sur leur moteur de recherche et Adsense. Tout le reste représente à peine 10 % de leur revenu annuel. Cela n’est pas forcément un problème en soi, mais quand la limite entre navigateur, moteur de recherche et services en ligne est brouillée, nous avons un problème. Et un gros.
Les entreprises qui marchent comptent sur leurs avantages compétitifs. Les moins scrupuleuses en abusent si elles ne sont pas supervisées. Quand votre navigateur vous force à vous identifier, à utiliser des cookies que vous ne pouvez pas supprimer et cherche à neutraliser les extensions de blocage de pub et de vie privée, ça devient très mauvais2. Encore plus quand vous prenez en compte le fait que chaque site web contient au moins un bout de code qui communique avec les serveurs de Google pour traquer les visiteurs, leur montrer des publicités ou leur proposer des polices d’écriture personnalisées.
En théorie, on pourrait fermer les yeux sur ces mauvaises pratiques si l’entreprise impliquée avait un bon bilan sur la gestion des données personnelles. En pratique cependant, Google est structurellement flippant, et ils n’arrivent pas à changer. Vous pouvez penser que vos données personnelles ne regardent que vous, mais ils ne semblent pas être d’accord.
Le modèle économique de Google requiert un flot régulier de données qui puissent être analysées et utilisées pour créer des publicités ciblées. Du coup, tout ce qu’ils font a pour but ultime d’accroître leur base utilisateur et le temps passé par ces derniers sur leurs outils. Même quand l’informatique s’est déplacée de l’ordinateur de bureau vers le mobile, Chrome est resté un rouage important du mécanisme d’accumulation des données de Google. Les sites web que vous visitez et les mots-clés utilisés sont traqués et mis à profit pour vous offrir une expérience plus « personnalisée ». Sans une limite claire entre le navigateur et le moteur de recherche, il est difficile de suivre qui connaît quoi à votre propos. Au final, on accepte le compromis et on continue à vivre nos vies, exactement comme les ingénieurs et concepteurs de produits de Google le souhaitent.
En bref, Google a montré à plusieurs reprises qu’il n’avait aucune empathie envers ses utilisateurs finaux. Sa priorité la plus claire est et restera les intérêts des publicitaires.
Voir au-delà
Une compétition saine centrée sur l’utilisateur est ce qui a provoqué l’arrivée des meilleurs produits et expériences depuis les débuts de l’informatique. Avec Chrome dominant 60 % du marché des navigateurs et Chromium envahissant la bureautique sur les trois plateformes majeures, on confie beaucoup à une seule entreprise et écosystème. Un écosystème qui ne semble plus concerné par la performance, ni par l’expérience utilisateur, ni par la vie privée, ni par les progrès de l’informatique.
Mais on a encore la possibilité de changer les choses. On l’a fait il y a une décennie et on peut le faire de nouveau.
Mozilla et Apple font tous deux un travail remarquable pour combler l’écart des standards du Web qui s’est élargi dans les premières années de Chrome. Ils sont même sensiblement en avance sur les questions de performance, utilisation de la batterie, vie privée et sécurité.
Si vous êtes coincés avec des services de Google qui ne marchent pas sur d’autres navigateurs, ou comptez sur Chrome DevTools pour faire votre travail, pensez à utiliser Vivaldi3 à la place. Ce n’est pas l’idéal —Chromium appartient aussi à Google—, mais c’est un pas dans la bonne direction néanmoins. Soutenir des petits éditeurs et encourager la diversité des navigateurs est nécessaire pour renverser, ou au moins ralentir, la croissance malsaine de Chrome.
Je me suis libéré de Chrome en 2014, et je n’y ai jamais retouché. Il est probable que vous vous en tirerez aussi bien que moi. Vous pouvez l’apprécier en tant que navigateur. Et vous pouvez ne pas vous préoccuper des compromissions en termes de vie privée qui viennent avec. Mais l’enjeu est bien plus important que nos préférences personnelles et nos affinités ; une plateforme entière est sur le point de devenir un nouveau jardin clos. Et on en a déjà assez. Donc, faisons ce que nous pouvons, quand nous le pouvons, pour éviter ça.
![Kae [CC BY-SA 3.0 (https://creativecommons.org/licenses/by-sa/3.0)], via Wikimedia Commons](https://commons.wikimedia.org/wiki/File:Power_connector_Legrand_32A.jpg){kind=link}
_-_Google_Art_Project_-_edited.jpg){kind=link}
![Codex Bodmer – Frater Rufillus (wohl tätig im Weißenauer Skriptorium) [Public domain]](https://commons.wikimedia.org/wiki/File:Codex_Bodmer_127_244r_detail_Rufillus.jpg){kind=link}