Le créateur de htmx, Carson Gross, croit à l'avenir des programmeurs : les deux piliers du métier

Carson Gross, créateur de la bibliothèque htmx, ramène la programmation à deux points et en tire un pronostic : les outils d'IA ne mettront pas fin au métier. Simon Willison a isolé un extrait de son essai « Yes, and... », publié sur htmx.org, dans un billet distinct, et la citation a vite circulé dans les milieux professionnels. La formule est brève, mais elle s'inscrit bien dans le débat sur l'utilité des développeurs quand ce sont des modèles qui écrivent le code.

Deux tâches plutôt qu'une liste de technologies

Gross définit la programmation par deux éléments. Le premier : résoudre des problèmes avec des ordinateurs. Le second : apprendre à maîtriser la complexité qui naît au fil de ces solutions. Cette définition ne mentionne ni langages, ni frameworks, ni même le mot « code » au sens d'un ensemble de lignes. Il décrit le métier par son résultat et par sa discipline.

Il en tire une conclusion prudente. Gross écrit qu'il a du mal à imaginer un avenir où la capacité à résoudre des problèmes sur ordinateur et à garder la complexité des solutions sous contrôle serait moins valorisée qu'aujourd'hui. Pour lui, la profession restera donc viable après l'arrivée des outils d'IA. C'est un pari sur la solidité de ces compétences, pas une prévision sur le nombre d'emplois ou le niveau des salaires.

Pourquoi miser sur la complexité ?

Le second point de cette formule est plus intéressant que le premier. Les modèles de langage s'en sortent bien sur des tâches locales : une fonction, un test, une migration, une configuration. Mais chaque fragment généré agrandit la base de code, et toute base de code finit par s'alourdir de dépendances, de conventions et d'exceptions. Qui veille à ce que le système reste compréhensible dans un an, quand la moitié du code a été écrite à partir de suggestions ? Gross répond : celui qui sait gérer la complexité. Tant que le modèle ne prend pas cette responsabilité entièrement à sa charge, la demande pour ce profil se maintient.

Le contexte de l'auteur compte aussi. Gross est connu comme le créateur de htmx, une bibliothèque qui construit des interfaces autour de l'hypertexte et réduit délibérément la quantité de code côté client. Pour lui, la complexité est un ennemi permanent, et sa position apparaît comme le prolongement de cette philosophie. L'essai original n'est pas reproduit en entier dans ce matériau ; nous nous en tenons donc à ce que dit la citation.

Points clés

• Selon Gross, la programmation comprend deux composantes : résoudre des problèmes avec des ordinateurs et gérer la complexité.
• Il estime que la valeur de ces compétences ne baissera pas dans un avenir prévisible.
• Il voit les outils d'IA comme un complément du métier, non comme son remplacement. Le titre de l'essai, « Yes, and... », va dans ce sens.
• La thèse est formulée comme un jugement personnel de l'auteur et n'est étayée par aucun chiffre sur le marché du travail.
• Simon Willison a publié la citation avec les tags computer-science, careers et ai.

Ce que cela change pour les développeurs et les équipes

La principale conclusion pratique concerne la formation et le recrutement. Si la valeur réside dans la formulation du problème et le contrôle de la complexité, mieux vaut investir dans la pensée architecturale, la lecture du code d'autrui, la décomposition des tâches et la capacité à renoncer au superflu. Les modèles suggèrent vite la syntaxe et les API, mais la décision de ce qu'il faut construire et de la manière de le maintenir, ils la laissent encore à l'humain.

Pour les managers, c'est l'occasion de revoir leurs métriques. Le volume de code généré dit peu de choses. Il est plus utile de mesurer en combien de temps une nouvelle recrue comprend le système, combien de temps demande une modification et combien de dépendances la dernière release a ajoutées. Pour les débutants, le conseil est simple : utiliser les outils d'IA, mais décortiquer chaque solution jusqu'à pouvoir l'expliquer sans aide.

La citation de Gross ne prouve pas que le marché du travail encaissera le choc, et il n'insiste pas sur ce point. Il propose un critère : tant qu'on attend d'un développeur qu'il résolve des problèmes et tienne la complexité en bride, le métier est nécessaire. Ce critère devra être vérifié par la pratique.