En février 2024, j’ai donné un talk qui s’appelait Hype Driven Development. En juin de la même année, j’en ai remis une couche au Devfest Lille avec Maîtriser la Hype : Passion versus Raison. Le message tenait en une phrase : choisis tes technos avec la raison, pas avec la hype.
Deux ans plus tard, je fais du développement augmenté par IA tous les jours, et j’adore ça.
Donc soit je me suis assis sur mon propre talk, soit il se passe quelque chose qui mérite mieux qu’un haussement d’épaules. J’ai pris le temps de me poser la question honnêtement. Voilà où j’en suis.
Ce qui ne me hype pas : aller plus vite
Autant commencer par là, parce que c’est l’argument qu’on entend partout et c’est pas le meilleur.
C’est aussi celui où les chiffres sont les moins flatteurs. En 2025, METR a fait passer un essai randomisé à seize développeurs open source expérimentés, sur 246 tâches, dans des repositories qu’ils connaissaient depuis cinq ans en moyenne. Résultat : 19 % plus lents avec les outils d’IA que sans. Et le meilleur : les mêmes développeurs estimaient après coup avoir été 20 % plus rapides.
C’est l’étude qu’on me sort systématiquement quand je dis que je suis hypé. Sauf que si on la lit vraiment, elle est plus intéressante que ça.
METR est revenu dessus en février 2026 pour annoncer qu’ils changeaient de protocole. Leur constat est clair : les développeurs refusaient de travailler sans IA même payés 50 $/heure, et surtout ils évitaient de soumettre les tâches sur lesquelles ils pensaient que l’IA les aiderait le plus. Autrement dit, l’expérience se vidait toute seule des cas où ça marche. Ils écrivent noir sur blanc que le vrai gain pourrait être bien plus élevé sur les tâches qui sortent de l’échantillon.
Une étude honnête qui dit « notre méthode ne mesure plus ce qu’on croyait » vaut mieux qu’un chiffre rond qu’on affiche sur LinkedIn.
Mais tout ce débat mesure la mauvaise chose.
Taper du code n’a jamais été mon goulot d’étranglement. Si mon métier se résumait à produire des lignes, ça ferait quinze ans que je m’ennuie.
Le vrai changement : le travail est remonté d’un cran
Ce qui me hype, c’est que la partie intéressante du métier a pris de la place.
Avant, une journée typique, c’était : réfléchir vingt minutes, puis passer une heure à transcrire cette réflexion en code. La réflexion était le petit bout. La transcription était le gros (en termes de temps).
Aujourd’hui, la transcription est accélérée. Ce qui reste, c’est formuler l’intention : qu’est-ce qu’on construit, dans quel ordre, avec quels compromis, et qu’est-ce qu’on refuse de faire. C’est exactement le travail que je préfère, et c’est celui qui remplit mes journées maintenant.
Le diagramme n’a pas d’échelle, et c’est volontaire : je n’ai pas chronométré mes journées. Mais la forme, elle, est correcte.
Ce déplacement a un effet secondaire que je n’avais pas vu venir : il rend les bonnes questions d’architecture beaucoup plus rentables. Quand écrire trois variantes coûtait trois jours, on choisissait sur intuition et on assumait. Quand ça coûte un après-midi, on peut réellement aller voir. Les compromis dont je parlais dans mon article sur PACELC ne sont plus des débats autour de la théorie : on peut les prototyper, les tester.
Il n’y a pas que l’écriture du code qui est augmentée
C’est sur l’écriture du code que le changement est le plus visible, mais ce n’est pas le plus important. L’utilisation de l’IA m’aide aussi énormément sur la partie cadrage : une session de questions-réponses me permet d’être challengé sur les designs que je propose et de m’assurer de ne laisser aucun angle mort dans mes spécifications.
Dans la compréhension aussi : quand je dois intégrer et décortiquer un code que je ne connais pas, l’IA me permet d’avoir rapidement des analyses plus ou moins poussées et accélère grandement ma capacité à intervenir.
La relecture devient une compétence critique
C’est le changement le plus concret dans mon quotidien, et celui dont on parle le moins.
Une revue de code classique cherche des erreurs : un cas non géré, une variable mal nommée, une requête dans une boucle. On lit du code écrit par quelqu’un dont on connaît les habitudes, et on sait où regarder.
Relire du code généré, ce n’est pas ça. Le code est souvent propre, cohérent, bien nommé, et il passe les tests. Tests qu’il a parfois écrits lui-même, d’ailleurs. L’erreur n’est presque jamais dans la ligne.
Elle est dans l’intention que personne n’a formulée.
Un retry ajouté « par sécurité » sur un appel qui n’est pas idempotent. Un cache dont personne n’a décidé la durée de vie. Un catch qui avale une erreur que quelqu’un, quelque part, avait besoin de voir. Rien de tout ça n’est un bug au sens strict. Ce sont des décisions prises par défaut, par un truc qui n’avait aucun moyen de savoir qu’il en prenait une.
Repérer ça demande une compétence différente de celle que j’ai passé quinze ans à construire. Il faut lire du code en se demandant non pas « est-ce que c’est faux ? » mais « qui a décidé ça, et est-ce que quelqu’un l’a décidé ? ».
Je trouve ça passionnant. Et je ne connais personne qui ait une méthode propre pour le faire. C’est très exactement le genre d’inconnu que j’aime.
Certains ne relisent même plus le code et font entièrement confiance au filet de sécurité qu’ils construisent avec leurs tests (par exemple le célèbre Uncle Bob, qui a fait pas mal de remous sur les réseaux avec ça cet été).
Pour ma part, j’ai pris le parti que l’IA ne bosserait pas à ma place mais pour moi. Je continue donc de progresser en programmation, et ça passe par relire le code produit, qui parfois m’apprend des choses et me permet de m’améliorer.
Le métier dans cinq ans, d’après moi
Quelques paris. Je les écris pour pouvoir me relire et avoir tort en public.
Le coût d’une idée va s’effondrer, et ça va être la meilleure partie. J’ai un fichier de notes plein de projets que je n’ai jamais lancés parce que la marche d’entrée était trop haute pour mes soirées. Cette marche est en train de descendre. On va voir arriver une vague de logiciels bizarres, spécifiques, faits par une seule personne pour trois cents utilisateurs. Le genre de chose qui n’a jamais eu de modèle économique mais qui rend la vie meilleure. C’est ce qui me hype le plus, très loin devant les gains de productivité en entreprise.
La valeur va se déplacer vers le jugement. Savoir quoi ne pas construire, sentir qu’une abstraction va coûter cher dans six mois, dire non à une fonctionnalité. Ça ne s’automatise pas, parce que ça ne se formule pas sous forme de tâche.
Écrire du code va redevenir un choix. Pas une corvée disparue, un choix. Il y a des morceaux que je continuerai à écrire à la main parce qu’ils sont le cœur du truc, ou parce que j’ai envie. Comme l’animation de particules de ce site à l’époque : personne n’avait besoin que je la fasse moi-même, et c’était tout l’intérêt.
Et l’entrée dans le métier va se durcir. C’est le point qui me préoccupe vraiment. Les tâches sur lesquelles j’ai appris, le CRUD un peu bête, le bug de niveau deux, la petite feature isolée, sont précisément celles qu’on délègue le plus facilement. Si on supprime le terrain d’entraînement, on récolte ce qu’on mérite dans dix ans. Je n’ai pas de solution propre. Je pense juste que c’est la vraie question du métier en ce moment, et qu’elle est nettement moins discutée que le classement des modèles.
Enfin, le monde des ESN va bouger. Fini les grandes équipes de 40 devs à aligner sur un projet : je suis persuadé que le futur, ce sont des équipes de 2 à 3 personnes augmentées par l’IA, et que le modèle va s’orienter encore plus vers de la production au forfait ou à l’unité d’œuvre que vers de la prestation en régie comme on la connaît. Je dis ça depuis la place du cofondateur, et c’est ce qui rend le pari inconfortable : la régie facture du temps, et c’est précisément le temps qui se compresse. Un modèle qui vend des jours-homme n’a aucun intérêt à ce que ses équipes aillent trois fois plus vite. Un modèle qui vend un résultat, si.
Ce que je surveille quand même
Je suis enthousiaste, pas naïf. Deux choses me font douter.
La première, c’est le code que plus personne dans l’équipe ne comprend. Pas du code illisible : du code que personne n’a eu besoin de comprendre pour le livrer. Ça se paye toujours, et ça se paye au pire moment.
La seconde, c’est ma propre perception. L’écart entre les 19 % mesurés et les 20 % ressentis dans l’étude METR est le résultat le plus solide de tout ce débat, et il ne parle pas des outils : il parle de nous. Je ne suis pas un bon juge de ma propre productivité, et je ne vois pas pourquoi je ferais exception.
Donc j’y vais à fond, en sachant que mon ressenti n’est pas une mesure.
Au final
Mon talk de 2024 ne disait pas « méfie-toi de tout ». Il disait : sache pourquoi tu y vas.
La hype n’a jamais été le problème. Le problème, c’est la hype sans raisons : adopter un truc parce qu’il est partout, puis reconstruire dix-huit mois plus tard. Là, j’ai des raisons, elles sont dans cet article, et elles sont falsifiables : si dans deux ans je passe toujours mes journées à corriger du code que je n’ai pas écrit sans que la partie conception ait grossi, c’est que je me suis trompé.
Je préfère largement écrire ça maintenant que le découvrir tranquillement dans mon coin.
Si vous vivez la même chose ou l’inverse, ce qui m’intéresse encore plus, écrivez-moi à william@lmns.fr ou passez me dire bonjour sur LinkedIn. C’est typiquement le genre de sujet où je préfère les contre-arguments aux approbations.
Sources
- METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, juillet 2025 (papier)
- METR, We are Changing our Developer Productivity Experiment Design, février 2026