L'astéroïde qui s'abat actuellement sur le développement web front-end

Par Nolan Lawson

Bon nombre des formateurs que j'admire dans le domaine du développement web front-end semblent soit se retirer, soit réduire leurs efforts : Axel Rauschmayer, Salma Alam-Naylor, Josh W. Comeau, pour n'en citer que quelques-uns. D’autres figures de proue bien connues, comme Kent C. Dodds, Addy Osmani, Rachel Nabors et Lydia Hallie, ont cessé de parler de développement front-end pour se consacrer à… eh bien, devinez un peu.

Je n’ai jamais gagné ma vie en parlant de développement web, mais je tiens ce blog et j’ai animé des conférences et des podcasts sur des sujets qui me passionnent. Récemment, par exemple, j’ai pris un malin plaisir à expliquer tous les tenants et aboutissants des performances CSS : le fonctionnement du Shadow DOM, celui du moteur de style du navigateur, les pièges du CSS-in-JS, etc.

Juste pour le plaisir, j’ai décidé de demander à Claude Sonnet comment il gérerait une trace Chrome présentant des coûts élevés de « calcul de style ». C’est l’une de mes énigmes préférées, car c’est le genre de chose sur laquelle j’ai vu des développeurs web – même les plus expérimentés ! – trébucher encore et encore. Claude a donné une réponse tout à fait admirable.

De nos jours, face à un site web qui met du temps à se charger, même en tant que personne ayant écrit sur les performances des navigateurs pendant des années et ayant littéralement travaillé au sein d’une équipe dédiée à ce sujet, je me contenterais probablement d’envoyer une trace Chrome à Claude Code pour qu’il suggère des améliorations. En fait, c’est exactement ce que j’ai fait dans le cadre de mon travail et j’ai obtenu de bons résultats.

L’avenir du développement front-end

Alors, qu’en est-il de la formation des développeurs front-end ? Manifestement, la situation n’est pas très réjouissante ; j’aimerais pouvoir apporter des réponses plus encourageantes à ceux qui, comme moi, tiraient autrefois une grande satisfaction à essayer de relever le niveau des développeurs front-end partout dans le monde. J’ai toutefois quelques hypothèses, et je pense que le problème mérite encore qu’on s’y attarde.

La question centrale est de savoir quelle place occupera le développement front-end lui-même dans cette nouvelle ère. Malheureusement, j’ai l’impression que plusieurs tendances vont à l’encontre d’un investissement accru dans les connaissances front-end :

Il est moins risqué de confier le front-end à un agent. Si vous utilisez un agent pour écrire une migration de base de données, vous voudrez probablement la soumettre à plusieurs cycles de révision de code par IA, l’examiner minutieusement vous-même, la tester d’abord en environnement de préproduction, etc. En revanche, si vous écrivez un composant React avec un agent, le risque de le déployer en production sans trop y réfléchir est (généralement) bien moindre.

Notez que je ne dis pas qu’il n’y a aucun risque : l’agent pourrait compromettre l’accessibilité, provoquer une boucle infinie bloquant les utilisateurs, etc. Mais en général, le code front-end est bien plus éphémère et remplaçable que d’autres types de code. Je m’attends donc à ce que de nombreux codeurs utilisant l’IA se sentent à l’aise de laisser simplement leur agent s’en charger sans supervision (pour le meilleur ou pour le pire).

L’expérience développeur (DevExp) perd globalement de son importance. Une grande partie des débats antérieurs à l’ère des grands modèles de langage (LLM) dans le domaine du front-end portait sur l’ergonomie par opposition aux résultats : l’article « The ‘developer experience’ bait-and-switch » d’Alex Russell en est un excellent exemple. Autre exemple : Svelte et Solid ont longtemps soutenu que leur ergonomie conduisait à de meilleurs résultats que React : moins de code, de meilleures performances, etc.

Dans le même temps, Cursor et Viget ont publié des articles de blog sur la migration de leurs bases de code, respectivement depuis Solid et Lit, vers React. Étant donné que les réécritures sont moins coûteuses avec les agents, cela peut paraître un peu surprenant : pourquoi ne pas passer au framework plus performant et moins verbeux ? La réponse (explicite dans le cas de Cursor, et je soupçonne qu’il en va de même pour Viget) est bien sûr : « les agents connaissent React ». Pour le meilleur ou pour le pire, React est largement surreprésenté dans les poids d’entraînement, et « l’expérience des agents » commence à primer sur l’expérience des développeurs.

Les normes finiront par rattraper leur retard. Je suis éloigné du domaine des normes web depuis quelques années maintenant, il s’agit donc là d’une pure spéculation de ma part. Mais j’imagine qu’une grande partie des efforts visant à améliorer l’ergonomie de la création de sites web – de meilleurs raccourcis CSS, une syntaxe JavaScript plus concise, etc. – seront perçus comme moins importants par rapport à ce qui fait réellement la différence en termes de performances, de fonctionnalités, etc. Au final, cela ne change pas grand-chose pour un agent d’écrire trois lignes de CSS au lieu d’une, et de toute façon, l’utilisation de la nouvelle syntaxe pourrait en réalité s’avérer plus difficile, car il faudrait former l’agent à des aspects qui ne figurent pas dans ses poids d’apprentissage.

D’une certaine manière, cette évolution est peut-être déjà en cours. Je me souviens qu’il y a plusieurs années, lors de la conférence TPAC, bien avant le boom du codage par IA, j’avais dit à un membre de l’équipe Chrome que je travaillais sur les normes relatives aux composants Web. Il m’avait répondu que cela ne l’intéressait pas, car ces API n’avaient d’incidence que sur l’expérience développeur et ne rendaient pas réellement le navigateur plus performant (par exemple, le projet Fugu). Cela m’a marqué, car c’est un argument pertinent : les API telles que le shadow DOM et les éléments personnalisés ne confèrent aucun nouveau « super-pouvoir » aux développeurs web ; elles modifient simplement où et comment le code est écrit. Je m’attends à ce que ces aspects passent au second plan à mesure que la programmation par IA prendra le relais.

Cela ne signifie pas que les normes disparaîtront des sujets que les développeurs front-end doivent suivre, mais j’imagine que l’accent sera moins mis sur « utilisez cette nouvelle syntaxe » (une source inépuisable de sujets pour les conférences et les articles) et davantage sur « voici les nouvelles fonctionnalités qui émergent ». Et je prédis que ce dernier groupe sera bien plus restreint que le premier, car ces fonctionnalités ont tendance à susciter davantage de controverses au sein des organismes de normalisation et le vivier de fonctionnalités disponibles est tout simplement plus limité.

Quel avenir pour la formation au développement front-end ?

Comment le domaine de la formation au développement front-end peut-il donc s’adapter à cet avenir hostile ? Pour éviter un tableau trop sombre, voici quelques pistes positives dans lesquelles il pourrait s’engager, selon moi.

Tout d’abord, les agents doivent toujours être formés à la vision d’ensemble. Les agents et les équipes de développement semblent adorer écrire en React, et plus particulièrement des SPA, mais les SPA ne sont pas la solution à tout. Vous pouvez gaspiller beaucoup de jetons en demandant à un agent d’écrire un gros SPA complexe pour votre site marketing, puis de corriger tous les bugs liés au bouton « Retour », à l’état de focus, aux performances, etc., ou vous pouvez simplement choisir un framework MPA comme Astro ou Eleventy et en rester là. Ces frameworks seront peut-être un peu plus difficiles à maîtriser pour les développeurs (en particulier Astro, car il ressemble un peu à React sans vraiment l’être), mais je pense que comme vous écrivez environ 50 % de code en moins au total, cela n’aura pas d’importance.

Deuxièmement, la création de sites web adaptés aux développeurs sera probablement une démarche fructueuse dans un avenir proche. Le projet « is-agentic » de Vercel en est un bon exemple. Ironiquement, cela renvoie aux principes fondamentaux que les sites web destinés au grand public auraient de toute façon dû respecter : contenu rendu côté serveur, accessibilité adéquate, vitesse de chargement des pages, etc. Mais si le simple fait d’y ajouter le mot « IA » suffit à susciter l’intérêt des gens, alors je suis tout à fait pour.

Notez que je suis un peu moins optimiste sur ce deuxième point, car je ne suis pas sûr que le Web survive même sous sa forme actuelle à mesure que les agents gagnent en importance. Si je veux savoir combien coûte un vol de Seattle à Paris, je préfère de loin m’adresser à un agent plutôt que de cliquer sur une série exaspérante de boutons sur un site web qui met du temps à se charger. La seule raison pour laquelle je ne peux pas le faire, c’est parce que ces sites bloquent explicitement les bots ou ne proposent pas d’interface de programmation (API), mais je suis sûr que plusieurs start-ups trépignent d’impatience à l’idée de résoudre ce problème. Je ne suis donc pas certain que la situation actuelle soit viable à long terme.

Troisièmement, nous pouvons proposer des services de conseil pour ces monstruosités codées à l’instinct. Une quantité massive de code front-end généré par l’IA est actuellement produite, et une partie de ce code (pour reprendre une expression de Claude) deviendra certainement « porteuse ». Si ces sites web sont lents, non conformes et criblés de failles de sécurité, il ne suffira peut-être pas de demander à l’agent : « Répare mon site web, s’il te plaît. » Il pourrait y avoir là une opportunité pour une véritable expertise, surtout si de l’argent est en jeu et que les connaissances du codeur « à l’instinct » en matière de développement web ne vont pas plus loin que « les sites web sont des applications hébergées sur Internet ».

(Je reconnais que c’est le plus fragile de mes trois arguments, car je peux tout à fait imaginer que la prochaine génération d’applications web « auto-réparatrices » éclipsera l’expert moyen d’ici 2027...