Conclusion et prospective

Je vais commencer par quelque chose de peu professionnel : cette année, j'ai repris du goût au développement.

Ça faisait longtemps. Ce n'est pas que le métier m'ennuyait, c'est qu'il traînait une frustration que j'avais fini par accepter comme une fatalité. J'ai toujours eu le code dans la tête très vite : en quelques jours, l'architecture est là, je vois où vont les morceaux et comment ils s'emboîtent. Et ensuite il fallait six mois pour le taper. Six mois pendant lesquels je n'inventais plus rien, je transcrivais. L'écart entre la vitesse à laquelle j'imagine et la vitesse à laquelle je produis, c'était ça, le vrai coût du métier. Et je ne l'avais jamais formulé comme un problème, parce qu'on ne formule pas comme un problème ce qu'on croit être la nature des choses.

Depuis l'arrivée de Claude Code, cet écart s'est refermé. J'écris à peu près aussi vite que je conçois. J'ai du mal à faire comprendre à quel point c'est agréable quand on a attendu trente ans.

Sauf que je n'écris plus vraiment de code

Et c'est là que ça devient intéressant. Parce que si je regarde honnêtement ce que je fais de mes journées, ce n'est plus de l'écriture. C'est de la conception. Je dessine des arborescences, je décide de ce qui se connecte à quoi, j'articule des processus, je place les limites et je choisis les points de contrôle. Le fait que tout cela finisse en lignes de code commence à ressembler à un détail d'exécution.

Antonio Goncalves a posé le mot en #357 : nous ne sommes pas des codeurs, nous sommes des développeurs. Adnan Aita disait la même chose autrement en #339 : le métier n'a jamais été d'écrire du langage machine, mais de comprendre un problème et d'y apporter une solution. Ils ont raison tous les deux, et ça m'agace un peu : ce que je vis comme une révolution personnelle n'est peut-être que le retour à la définition d'origine. Le métier a changé radicalement, et il n'a pas bougé d'un pouce. Les deux sont vrais en même temps, et c'est le résumé le plus honnête que je puisse faire de cette saison.

Le marché, lui, ne fait pas de philosophie

Il faut être clair : l'effet sur l'emploi est réel, et ce livre ne l'a pas édulcoré. Les chiffres du chapitre 3 sont là, les témoignages aussi, et je ne vais pas conclure douze mois de conversations en expliquant que tout va bien.

Mais je ne partage pas la lecture qui en fait une fin. Ma conviction, c'est que le nombre de gens capables de créer quelque chose va exploser, et qu'en explosant il va faire exploser le besoin de gens capables de créer quelque chose de bien. J'ai déjà servi l'analogie en plateau : YouTube n'a pas tué le cinéma, il a mis une caméra dans toutes les mains, et depuis il n'y a jamais eu autant de travail pour ceux qui savent réellement raconter en images. Je crois qu'il va se passer exactement la même chose avec les applications. Quand tout le monde pourra en faire une, savoir en faire une bonne deviendra la compétence rare. Et pour ce métier-là (créateur d'applications, faute de meilleur mot), je ne vois pas qui est mieux placé que les développeurs et les développeuses.

Est-ce que j'en suis certain ? Non. C'est un pari, et il est daté : je le remets sur la table au prochain bilan.

Les juniors apprendront comme nous avons appris

On a beaucoup parlé cette année de la génération qui arrive, et de ce qu'elle risque de ne jamais apprendre. La question est légitime, elle traverse tout le chapitre 3, et je ne la balaie pas.

Mais je nous trouve un peu amnésiques. Nous n'avons pas appris ce métier dans des livres ni en regardant des seniors faire proprement. Nous l'avons appris en cassant la production un vendredi soir, en passant trois jours sur un bug qui tenait dans une ligne, en découvrant à nos dépens pourquoi on ne fait pas ça comme ça. Nous avons appris par nos erreurs, et surtout par le fait d'avoir eu à les réparer nous-mêmes. Il n'y a aucune raison que cela change. Les erreurs seront différentes, puisqu'elles porteront sur ce qu'on a laissé passer plutôt que sur ce qu'on a écrit, mais le mécanisme d'apprentissage, lui, est le même depuis toujours. Notre responsabilité n'est pas de leur épargner les erreurs. Elle est de leur laisser un système où se tromper reste possible, visible et réparable.

Ce que je retiens vraiment de cette année

S'il fallait n'en garder qu'un, ce serait l'épisode de Yacine Hmito sur le Lean (#362). Il y explique que l'explosion du code généré est d'abord un problème de flux : on a multiplié par dix le débit de l'étape de réalisation sans toucher à ce qui vient après, et toute la pression s'est déplacée sur le contrôle qualité. Sa réponse n'est pas de supprimer ce contrôle, mais de s'en servir pour corriger le système en amont, afin que les mauvaises pièces cessent d'être produites.

Ce que j'en tire va peut-être plus loin que ce qu'il disait, alors je l'assume comme ma lecture : il faudrait commencer par la fin. Se doter d'une chaîne de validation capable de juger le code aussi bien qu'un humain le ferait en revue ; puis, seulement une fois qu'elle tient, ouvrir le robinet de la génération. Remonter la chaîne étape par étape au lieu de la dévaler. C'est plein de bon sens, ça demande de la patience, et c'est pour cette raison que presque personne ne le fait. Nous avons collectivement branché la pompe avant de vérifier que le tuyau tenait. Je ne suis pas sûr que nous ayons fini de le payer.

Trente ans plus tard, j'ai toujours mon clavier

Je suis tombé amoureux de ce métier il y a plus de trente ans, en découvrant que je pouvais créer des choses avec un clavier. Pas en apprenant un langage, pas en décrochant un diplôme : en voyant qu'un objet existait à l'écran parce que j'avais tapé quelque chose.

Depuis, à peu près tout a changé. Les langages, les machines, les méthodes, les équipes, et cette année l'outil lui-même. Et pourtant, au fond, rien n'a changé du tout. J'ai toujours mon clavier, et je fais toujours des choses.

Simplement, j'en fais beaucoup plus.