Ce matin, on m’a transmis l’article JavaScript broke the web (and called it progress), qui rejoint des points que je cherchais à exprimer ici.
Alors plutôt que de simplement répondre à l’auteur du fwd, je vais développer mon propos en rebondissant sur l’article.
Most websites are awful.
Premier problème, il ne donne aucun élément pour justifier cette affirmation, qui semble donc n’être qu’une opinion, ou l’expression d’un ressenti.
À titre personnel, les sites que j’utilise au quotidien ne me posent aucun problème.
Cependant, il existe des exceptions.
Pas plus loin qu’hier, j’ai été contraint de passer du temps sur le site de Canyon et, ça a été un enfer.
Déjà parce que ça ne fonctionne tout simplement pas sur Firefox.
Qu’ensuite, même sous Chrome, la modale de chat avec le SAV est trop petite et ne peut pas être redimensionnée, résultat le champ de saisie d’un message ne permet de voir que quinze caractères à la fois.
Et enfin, car les informations disponibles ne sont pas à jour : il a fallu attendre plus d’une heure entre le moment où j’ai réglé ma commande, reçu un email de confirmation, et le moment où le statut de celle-ci a été mis à jour sur la page de mon compte client.
Si certains de ces problèmes peuvent, avec beaucoup d’efforts, être attribués à des choix techniques à la main des développeurs, la plupart sont le fruit de décisions bien plus haut dans la hiérarchie.
Je ne vais pas passer sur chaque point individuellement, car l’article est construit d’une manière suffisamment chaotique pour que cela ne soit pas pratique.
Je partage une partie de son constat : certaines stacks techniques modernes sont une catastrophe totalement absurde.
Par contre, je ne partage pas du tout son diagnostic.
Quand il parle du cult of developer experience, je pense qu’il se trompe.
Comme souvent, on cherche à faire porter aux développeurs une responsabilité qui n’est pas la leur.
J’entends souvent dire que les constructions immobilières modernes seraient de moins bonne qualité que celles d’il-y-a vingt ans ou plus.
Est-ce la faute des ouvriers qui travailleraient moins bien, ou qui utiliseraient des outils et méthodes de travail qui améliorent leur quotidien, tout en réduisant la qualité du résultat ?
Ou est-ce la faute des législations qui changent tous les mois ? Ou des promoteurs qui cherchent à maximiser leurs profits en choisissant les matériaux les moins chers et en réduisant toujours plus les délais ?
Pour illustrer ma réflexion, je vais prendre deux exemples que je connais bien, pour avoir encore été contraint de travailler avec très récemment : Vercel et Platform.sh.
On remarque tout de suite une chose : ce sont deux entreprises.
La première développe son propre framework, Next.js, tandis que la seconde est, comme son nom l’indique, une simple plateforme.
Ce que propose Vercel, à la base, ça a été effectivement créé en ayant la developer experience comme principal objectif.
Là où Wordpress(.com) ou YouTube, permettent aux créateurs de contenu de se focaliser sur la création du contenu, et s’occupent à leur place de toutes les autres contraintes techniques pour mettre à disposition de l’Internet mondial le dit contenu ; Vercel propose la même chose, mais pour les développeurs : focalisez-vous sur votre code, on s’occupe de son déploiement à l’échelle !
C’est ajouter de l’abstraction au service de certains créateurs. Et c’est, à la base, une bonne chose.
Cependant, tout comme un studio de cinéma ne va pas s’appuyer sur YouTube pour diffuser ses films, un éditeur qui crée un site n’est pas censé s’appuyer sur un service comme Vercel.
Car en ajoutant de l’abstraction, on perd immédiatement en contrôle.
Et, dans un monde sensé, aucun dirigeant ne devrait vouloir perdre le contrôle sur ses sources de revenus ; tout du moins pas pour le confort de ses petites mains.
Au contraire.
Et c’est là qu’arrive le vrai coupable de toutes ces catastrophes : l’argent.
Vercel c’est $563M de levées de fonds, Platform.sh c’est $187.3M.
Il ne faut pas être clairvoyant pour réaliser que quelque-chose ne va pas.
Aucune entreprise ne peut espérer devenir rentable auprès de ses investisseurs, qui lui ont injecté des centaines de millions de dollars, en s’adressant aux développeurs, pour déployer leurs petits sites bricolés dans leur coin.
Not in a million years.
Il faut alors changer de cible : les entreprises.
Comme tous les XaaS, les tarifs sont divisés en tiers ; généralement un tree-tier pour un usage personnel très limité ou pour faire un POC, un niveau intermédiaire avec un tarif fixe, puis un niveau Enterprise, sans tarif explicite, qui est à négocier avec les équipes commerciales.
C’est à ce niveau que la magie opère.
Les fonds des investisseurs, en majorité, ils ne sont pas utilisés pour améliorer le produit, mais pour faire venir des clients.
Quoi de mieux pour convaincre un DSI ou un PM d’adopter votre produit, que de lui accorder une ristourne de 50% sur sa facture ou de lui accorder plusieurs milliers de dollars de crédits gratuits ?
Récemment, à la demande d’un client, j’ai participé à un échange avec Platform.sh, qui lui promettait une grosse réduction sur sa facture d’hébergement s’il allait chez eux.
Suite à cet échange, j’ai passé plusieurs heures à expliquer au client que le service n’était pas du tout adapté à ses besoins, et que le gain financier court terme sur l’hébergement ne compenserait jamais les coûts impliqués par tout ce qu’il serait nécessaire de construire autour pour pouvoir adresser ses besoins tout en hébergeant le cœur de son applicatif sur Platform.sh.
Heureusement, il a fini par entendre raison, quand j’ai insisté sur la perte de contrôle.
Sans cette promesse d’argent, jamais il n’aurait envisagé de partir sur une telle solution fermée et propriétaire.
Car, oui, toutes ces solutions, non seulement elles font perdre du contrôle sur la vie quotidienne d’une application, mais en plus, elles enferment dans un écosystème propriétaire dont la seule façon de s’extraire est généralement de tout reconstruire.
Plus généralement, n’importe quel développeur pourra l’affirmer : ce n’est pas lui qui a la liberté de prendre des décisions aussi impactantes, puisqu’elles ont un lien direct avec les dépenses de son employeur.
Et même les développeurs les plus Stinsoniens finissent par reconnaître que le nouveau framework à la mode cette semaine n’est peut-être pas le plus adapté aux besoins.
Cependant, il existe des situations avec lesquelles les développeurs vont pousser à utiliser leur solution de prédilection ; mais ça, c’est un problème qui n’est pas propre aux développeurs, il s’applique à tous les êtres humains : c’est un biais cognitif.
Reste, quand même, que les développeurs ont un temps limité comme tout le monde, et que, pour décider d’apprendre à maîtriser un outil, ils ont besoin d’y être incités.
Ils peuvent l’être par leur employeur, qui décide de partir sur cet outil et demande à ses équipes de monter en compétence.
Mais aujourd’hui, il existe deux facteurs supplémentaires majeurs qui permettent aux entreprises éditrices de ces solutions de faciliter leur adoption : les influenceurs et les écoles/bootcamps.
Comme dans tous les autres domaines, le monde du développement a aussi maintenant ses influenceurs qui reçoivent de l’argent d’entreprises pour promouvoir auprès de leur communauté tel framework ou tel outil.
En parallèle, depuis les années 2010, de très nombreux programmes éducatifs à but lucratif se sont développés, sous la forme d’écoles privées ou plus simplement de bootcamps, qui souvent promettent à leurs étudiants clients de les former aux technologies les plus prometteuses pour rentrer confortablement sur le marché du travail.
Évidemment, comme leur but, c’est de faire de l’argent, ils n’hésitent donc pas à proposer, officiellement ou non, des programmes directement sponsorisés par des entreprises comme Vercel.
Résultat, quand une promotion arrive sur le marché du travail et qu’elle n’a étudié que Next.js plutôt que de faire du vanilla, comme elle l’aurait fait dans le public (blink blink), ça facilite le recrutement pour ceux qui voulaient faire un POC ou le concrétiser, et ça signale aux décideurs que le marché regorge de ressources maîtrisant Next.js ; donc, avec les crédits offerts de l’autre côté par les équipes commerciales, ce serait absurde de ne pas partir chez Vercel, non ?!
Dans les commentaires, quelqu’un parle également du CV des développeurs :
how can developers keep being employable if they stop pushing shiny modern frameworks skills in their CVs
Mais là-encore, ce ne sont pas les développeurs qui sont responsables.
Ce sont les recruteurs qui vont rejeter les CVs qui ne contiennent pas certaines buzzwords, sans nécessairement que l’entreprise cherche à recruter sur ces compétences.
C’est l’incompétence totale de certains recruteurs qui force les développeurs à enjoliver leur CV pour pouvoir passer le filtre des idiots et pouvoir échanger avec des personnes compétentes à l’étape d’après.
Ces mêmes recruteurs qui mettent en avant l’équilibre vie pro/vie perso dans l’entreprise… et qui demandent pourquoi l’historique GitHub du candidat semble vide ?!
Quand j’ai lu l’article, sur mon iPhone, je n’avais aucune information sur son auteur.
Le sous-titre Independant technical SEO consultant qui est visible sur la version desktop, ne l’est pas sur mobile.
Maintenant que j’ai cette information, je comprends mieux pourquoi il identifie certains problèmes, pourquoi il parle si souvent de SEO, et pourquoi une grosse partie de son diagnostic retombe sur les développeurs.
En effet, en tant que consultant SEO, il est nécessairement tributaire du travail des développeurs.
Sur son site, il explique lui-même qu’il travaille majoritairement avec WordPress.
Quand on sait qu’en avril dernier, 43% des sites web étaient propulsés par Wordpress, il est important de se rappeler du début de l’article : Most websites are awful.
Coïncidence ou réalité scientifique ?
Avec son système de plugins, qui est à la fois sa force et sa grande faiblesse, Wordpress permet à des non-développeurs de faire presque tout ce qu’ils veulent, de manière quasi autonome.
En partant d’un Wordpress, on peut faire un simple site vitrine, tout comme un site d’e-commerce complet.
Une fois authentifié sur le backoffice, un utilisateur peut modifier totalement l’aspect et le comportement du site, sans qu’aucun développeur ne soit impliqué.
Forcément, quelqu’un comme Jono apprécie la liberté que lui offre un tel outil dans son métier.
Mais ça vient avec énormément de contraintes, que ce soit en termes de sécurité, de fiabilité ou de scalabilité.
Il se plaint de la lenteur des sites pour l’utilisateur, mais pour servir de manière efficace un Wordpress à plusieurs dizaines de milliers d’utilisateurs, les problématiques côté ops sont 1000 fois plus complexes qu’une stack JavaScript qu’il n’apprécie pas.
Et il n’aborde pas la question des responsabilités.
Quand le marketing casse le Wordpress en ajoutant un plugin ou en modifiant directement le thème, ils vont immédiatement créer un ticket support pour se plaindre que le site ne marche plus, et que c’est forcément la faute des développeurs, qui auront alors la joie de devoir comprendre ce qui a été fait pour causer les problèmes, puis de remettre tout d’équerre… tout en justifiant que, non, ce n’est pas eux qui ont causé cela.
C’est en partie pour ces raisons qu’une partie des paradigmes courants réduisent le périmètre d’action de certains acteurs, tout en complexifiant le processus de publication des changements.
Oui, c’est terminé l’époque où on se connectait en (s)FTP au serveur de prod pour aller glisser/déposer un fichier.
Aucune équipe de sécurité sérieuse ne pourrait tolérer cela.
Même les développeurs n’ont pas un accès direct à la production.
Les pipelines de CI/CD que semble redouter Jono, elles servent (normalement), à ajouter de la sécurité, de la fiabilité et, par conséquent, permettre la scalabilité des applications.
Même quand il parle de faire des sites statiques plutôt que de sortir systématiquement la Grosse Bertha, il ne semble pas réaliser que les contraintes ajoutées sur le déploiement sont là pour la sérénité de tout le monde.
Ce n’est pas pour rien que, même pour ce site, j’ai mis en place de tels mécanismes.
Au final, si je suis d’accord sur une partie du constat, je suis en désaccord sur les causes ; ou tout du moins sur les seuls acteurs qui en porteraient la responsabilité.
Aujourd’hui, le développement est une industrie qui brasse des milliards et, par conséquent, elle est avant tout gouvernée par l’argent.
Et puisque l’argent pourrit les gens, il pourrit aussi leur code.
Une fois que l’on sait quel est son métier, cependant, on comprend mieux son propos.