Le silence du développeur qui ne code plus

Il y a quelque chose d'étrange qui se passe dans notre industrie. Ces derniers temps, je croise de plus en plus de devs qui me racontent la même histoire : leurs pull requests s'accumulent, leur output code est au rendez-vous, mais cela fait des semaines—parfois des mois—qu'ils n'ont pas tapé une seule ligne eux-mêmes.

Ce n'est plus de la science-fiction. C'est le quotidien. Et honnêtement, ça soulève des questions qui vont bien au-delà de la simple peur de perdre son job.

Le chagrin d'un artisan

Ce qui m'a frappé dans les témoignages qui circulent, c'est la nature de l'inquiétude. Ces développeurs ne craignent pas tellement la machine. Ils pleurent autre chose.

Ils regrettent cette lenteur délibérée qui permettait de comprendre un codebase en profondeur. Cette satisfaction de terrasser un algo récalcitrant. Ce rythme.meditatif entre la pensée et le clavier. Le code n'était pas qu'un métier. C'était une identité.

Et là, cette intimité avec la syntaxe, elle s'effrite.

L'analogie du jeu d'échecs

Quelqu'un avait сравненил la situation avec l'apparition des moteurs d'échecs. Au début, les joueurs se sont sentis menacés. Puis, quelque chose d'intéressant s'est produit : beaucoup de grands maîtres ont intégré ces outils pour analyser leurs parties, découvrir de nouvelles stratégies. Le jeu n'est pas mort. Il a évolué.

Avec les coding agents, on observe peut-être la même trajectoire. Sauf que les enjeux émotionnels sont différents. Aux échecs, le résultat est binaire. En développement, la frontière entre "ton code" et "le code de l'agent" est devenue floue—et c'est à la fois magnifique et flippant.

Le rôle qu'on ne nous a jamais formé à jouer

Le changement le plus déstabilisant n'est peut-être pas la baisse de code produit. C'est la transformation des demandes cognitives.

Le coding traditionnel réclamait une concentration profonde, permettait des heures de flow state. Avec l'IA, on demande maintenant du context-switching constant, de la reconnaissance de patterns à grande vitesse, une vigilance permanente. Ça ressemble davantage à de la modération qu'à de la création.

Je connais des devs qui rentrent épuisés après une journée passée à relire du code généré. Ils traitent plus d'informations, plus vite, mais sans ce rythme satisfaisant de construire quelque chose eux-mêmes. Leur journée ressemble davantage à du curate qu'à du craft.

Et il y a une ironie amusante : beaucoup de ces devs n'ont jamais voulu devenir manageurs. Ils ont choisi le code précisément pour bosser avec des machines, pas avec des gens. Pour résoudre des problèmes avec des réponses claires. Maintenant, leur rôle ressemble de plus en plus à celui d'un lead technique qui делегирует, revoit, fournit du contexte—sauf que leur délétué ne dort jamais et n'a jamais besoin d'un one-on-one.

Ce qui compte vraiment maintenant

Alors que faire ? Je ne pense pas qu'on puisse faire semblant que l'IA ne transforme pas notre métier. Ce train est parti.

Mais examinons ce qui garde de la valeur. La capacité de formuler clairement un problème. De décomposer des besoins en spécifications précises. De comprendre un système assez profondément pour guider une IA vers la bonne solution. Ces compétences deviennent rares—et précieuses.

Le développeur qui passait trois jours à implémenter une fonctionnalité? Il peut maintenant consacrer ce temps à architecturer un système entier qu'une IA contribue à construire. La levier a changé. Mais la réflexion compte toujours.

Il y a aussi quelque chose à accepter : élargissons notre définition de ce qui "compte". Tu as guidé une IA vers une solution ? Tu as repéré le bug subtil dans le code généré ? Tu as compris le contexte métier assez pour privilégier une approche plutôt qu'une autre ? Ce travail était bien réel. L'exécution a changé de forme. Pas l'effort intellectuel.

Le métier ne meurt pas—il mute

Mon avis : la douleur que ressentent beaucoup de devs est légitime. Elle mérite qu'on en parle.

Pendant des décennies, notre identité était liée à un ensemble précis d'activités : taper du code, debugger dans un terminal, voir les tests passer au vert. Ces activités ne vont pas disparaître entièrement. Mais elles ne constituent plus l'intégralité de l'histoire.

Les devs qui vont s'en sortir ne sont pas nécessairement ceux qui résistent le plus fort à l'IA. Ce sont ceux qui arrivent à intégrer ces outils dans une pratique qui garde du sens pour eux. Qui trouvent de nouvelles formes de créativité, de nouvelles sources de satisfaction.

Cela peut vouloir dire passer plus de temps sur la définition des problèmes—là où le jugement humain reste irremplaçable. Creuser les systèmes et l'architecture qu'une IA gère encore mal. Ou accepter un nouveau genre de rôle, plus proche du systems thinker ou du product engineer qui utilise le code comme un outil parmi d'autres.

Ce qu'on construit, pas seulement comment

Chez NameOcean, on parle beaucoup de "vibe coding"—l'idée que le développement moderne devrait moins ressembler à de la saisie de syntaxe et davantage à de l'expression d'intention créative. Cela ne veut pas dire que l'IA fait tout pendant qu'on se repose. Cela veut dire que le goulot d'étranglement passe de l'exécution mécanique à la clarté conceptuelle. Et la clarté conceptuelle, avouons-le, c'est un problème plus intéressant à résoudre.

Si tu te sens perdu en ce moment, c'est normal. Le sol bouge sous nos pieds. C'est déstabilisant pour tout le monde.

Mais souviens-toi : la curiosité qui t'a poussé à apprendre à programmer, le plaisir de résoudre des problèmes ardus, la fierté de construire quelque chose qui fonctionne—rien de tout cela ne doit disparaître. Ça va simplement prendre une forme différente de ce que tu avais imaginé.

Le métier ne meurt pas. Il mute. Et les devs qui s'adaptent—sans abandonner ce qui les a fait tomber amoureux de ce travail—vont peut-être découvrir quelque chose d'inattendu : une relation plus profonde, plus stratégique avec ce qu'ils construisent.

Et toi ? Comment tu vis cette transition ? Laisse un commentaire—pour toi aujourd'hui, c'est quoi "coder" ?