Le titre est volontairement provocateur. Mais il y a bien un avant et un après. Il y a quelques mois, j’écrivais encore l’essentiel de mon code à la main. Aujourd’hui, je passe plus de temps à décrire, relire et décider qu’à taper. Et je ne suis pas sûr de vouloir revenir en arrière.
Le jour où j’ai arrêté de taper
Je me souviens du moment où ça a basculé. Une migration pénible sur un site de destination : des dizaines de templates à adapter à un nouveau format de données Apidae. Le genre de tâche qu’on repousse au lendemain, puis au surlendemain. J’ai décrit le problème à Claude, dans le terminal, avec le dépôt ouvert. Il a lu le code, proposé un plan, modifié les fichiers, lancé les tests. Moi, j’ai relu.
Ce qui m’a frappé, ce n’est pas qu’il sache coder : les outils d’autocomplétion le faisaient déjà un peu. C’est qu’il comprenne un projet entier, avec son historique, ses bizarreries et ses conventions, et qu’il travaille dedans comme un collègue qui viendrait d’arriver… mais qui aurait lu tout le code dans la nuit.
Je ne suis plus payé pour taper du code. Je l’ai sans doute jamais vraiment été.
Ce que Claude fait mieux que moi
Soyons honnêtes, il y a des choses qu’il fait plus vite, et souvent mieux :
- Le code répétitif : formulaires, CRUD, composants Nuxt, contrôleurs Laravel ou Adonis, blocs Gutenberg.
- Les migrations et refactorisations : renommer, restructurer, mettre à jour une dépendance sur tout un projet.
- Lire un code qu’on ne connaît pas : reprendre un site développé par une autre agence n’a jamais été aussi rapide.
- Les tests et la documentation, ces tâches qu’on sait indispensables et qu’on bâcle quand le planning se resserre.
- Le prototypage : une idée le matin, une maquette cliquable l’après-midi, à montrer au client le lendemain.
Ce qu’il ne fait pas à ma place
Et c’est là que le titre est trompeur. Claude n’a pas « tué » le métier, il en a déplacé le centre de gravité. Il ne sait pas :
- Ce que veut vraiment le client, surtout quand le client lui-même ne le sait pas encore.
- Arbitrer entre délai, budget, performance et maintenabilité, avec les contraintes réelles d’un office de tourisme.
- Connaître le terrain : les subtilités d’un flux Apidae mal renseigné, d’un PMS capricieux, d’un hébergement qui ne met jamais ses dispos à jour.
- Garantir l’accessibilité, la sécurité ou l’éco-conception : il peut aider, mais l’audit et la responsabilité restent humains.
- Avoir du goût. Il propose, souvent bien. Mais choisir ce qui est juste pour un projet, c’est encore notre travail.
Il se trompe, aussi. Avec assurance, parfois. Une fonction qui n’existe pas, un cas limite oublié, une solution élégante mais inadaptée. D’où une règle simple : on ne livre que ce qu’on a compris.
Avant, maintenant
| Avant | Maintenant | |
|---|---|---|
| Ma journée | Écrire du code | Spécifier, relire, tester, décider |
| Compétence clé | Connaître la syntaxe | Savoir expliquer et savoir juger |
| Un prototype | Plusieurs jours | Quelques heures |
| Le code hérité | Une plongée de plusieurs jours | Une conversation |
| Le temps gagné | (il n’y en avait pas) | Accessibilité, performance, finitions |
Comment on travaille chez Mill
On n’a pas tout misé sur l’IA du jour au lendemain. On a testé, cassé, recommencé, dans notre laboratoire MillenIAl. Six règles sont restées :
- Le brief d’abord Avant de lancer quoi que ce soit, on écrit ce qu’on veut : le comportement attendu, les contraintes, les cas limites. Un prompt flou donne du code flou.
- Un fichier de conventions par projet Stack, structure, règles de nommage, commandes de test : Claude les relit à chaque session. C’est notre « onboarding » permanent.
- Des petites tâches Une fonctionnalité à la fois, un diff lisible. Si je ne peux pas relire le changement en dix minutes, la tâche est trop grosse.
- Chaque ligne est relue Rien ne part en recette sans qu’un humain ait lu, compris et assumé le code. Le nom dans le commit, c’est le mien.
- Les tests comme garde-fou On demande les tests en même temps que le code, et on vérifie qu’ils testent vraiment quelque chose.
- Pas de secrets, pas de prod Aucune clé d’API, aucune donnée client réelle dans les sessions. L’IA travaille sur des environnements de développement.
Alors, game over ?
Non. Le jeu a changé de règles, c’est tout. Les développeurs qui s’en sortiront ne sont pas ceux qui tapent le plus vite, mais ceux qui comprennent le mieux le problème, savent l’expliquer clairement et relisent avec exigence. En un mot : ceux qui pensent produit.
La vraie question, pour notre métier, c’est la transmission. Comment un développeur junior apprend-il à juger un code qu’il n’a pas écrit ? Chez nous, la réponse passe par le binôme : on relit ensemble, on explique, on conteste les propositions de la machine. L’IA écrit, l’équipe apprend.
Notre métier ne sera plus jamais comme avant. Franchement ? Tant mieux.
Un projet à prototyper vite, sans rien lâcher sur la qualité ? Parlons-en.