L'IA ne remplace pas les développeurs. Elle fait pire.

L'inquiétude qu'on s'est trompée

Voici une histoire tirée d'un article du développeur Michael Lawrence, et elle m'a marqué. Un développeur senior relit une pull request. Un assistant de codage IA (Claude Code) a refactorisé environ 400 lignes de code. Le diff semble propre. Les tests passent. Le développeur valide.

Deux jours plus tard, un bug apparaît en production. Quelqu'un creuse et trouve la cause : dans les 400 lignes, un contrôle null a silencieusement disparu. Le refactoring semblait correct, les tests étaient verts, et le filet de sécurité avait disparu sans que personne ne le remarque.

Le senior l'a raté. Pas parce qu'il est mauvais. Parce que le code généré par l'IA ne l'obligeait plus à regarder. Le code semblait bon, alors son regard s'est arrêté de chercher.

C'est l'histoire que personne ne raconte dans le débat « l'IA remplace les développeurs ». Il ne s'agit pas de perdre son emploi. Il s'agit de perdre son tranchant, une pull request validée à la fois.

Déformation, pas remplacement

Pensez aux compétences que vous utilisez pour écrire du logiciel : lire du code, repérer les bugs, remarquer les motifs, savoir où chercher quand quelque chose cloche. Ce n'est pas de la magie. Ce sont des muscles, et comme tous les muscles, ils se construisent par la résistance.

Pendant des années, cette résistance faisait partie du métier. Vous lisiez le code attentivement parce que personne d'autre ne le lisait à votre place. Vous débogguiez parce qu'il n'y avait pas de raccourci. Vous écriviez chaque ligne, et chaque ligne vous apprenait quelque chose.

Aujourd'hui, l'IA absorbe la résistance à votre place. Elle écrit le code répétitif. Elle explique l'erreur avant que vous ne la lisiez. Elle refactorise 400 lignes pendant que vous survolez le diff.

La friction était la leçon. L'IA supprime silencieusement la friction aux moments exacts où vous aviez l'habitude d'apprendre.

Les trois formes de la déformation

Selon où vous en êtes dans votre carrière, la pression vous plie différemment.

Les juniors : ils ne se forment jamais

La première année d'un junior servait à construire les bases : lire du code, raisonner sur la logique, faire des erreurs et les corriger. Ces erreurs sont le programme. Elles sont lentes, parfois gênantes, et c'est exactement comme ça que le cerveau apprend.

Un junior qui commence avec l'IA ne fait jamais ces erreurs. Il tape une instruction et le code apparaît. La première fois qu'il doit déboguer un vrai système, il n'a aucune carte. Il n'a jamais vu les états d'échec qui construisent l'intuition. Ce n'est pas l'IA qui l'a remplacé. C'est que le développeur ne s'est jamais formé — et personne ne le remarque avant qu'on retire les roulettes.

Les mid-levels : une formation en arrêt

Les développeurs mid-level sont le groupe le plus écrasé. Leurs compétences sont réelles mais pas encore automatiques. Chaque tâche confiée à l'IA est une tâche qu'ils ne pratiquent pas vraiment — et c'est précisément l'étape où la pratique devait les transformer en seniors.

Ils n'oublient pas. Ils arrêtent simplement de se former. Cinq ans passent, et l'écart entre leur niveau et celui qu'ils devaient atteindre grandit en silence.

Les seniors : l'atrophie

Les seniors n'ont pas besoin de l'IA pour apprendre. Ils en ont besoin pour remarquer des choses. L'histoire du contrôle null manquant est une erreur de forme senior. Les compétences sont là, mais l'attention n'y est plus. Quand le code arrive déjà poli, rien ne vous force à regarder de près.

Les compétences senior se maintiennent par l'usage. L'IA leur donne moins de matière à utiliser. La vivacité s'émousse d'une façon impossible à remarquer de l'intérieur.

Vous perdez ce que vous cessez de pratiquer

Rien de tout cela ne signifie qu'il faut jeter son ordinateur à la mer. L'erreur n'est pas d'utiliser l'IA. L'erreur est d'utiliser l'IA comme substitut à la réflexion, au lieu d'un outil qui travaille autour de votre réflexion.

Les personnes qui restent affûtées à l'ère de l'IA ne refusent pas les outils. Elles construisent une routine autour d'eux :

• Répartissez selon votre niveau. Donnez à l'IA ce que vous maîtrisez déjà : code répétitif, colle technique, migrations faites cent fois. Gardez pour vous ce qui est encore en train de vous former. C'est là qu'est la pratique.
• Laissez l'IA écrire, mais relisez comme si c'était vous. Un diff généré doit être lu avec la même méfiance que votre propre code. Si vous ne valideriez pas vos 400 lignes sans les lire, ne validez pas celles de la machine.
• Rendez votre rigueur externe. Puisque l'attention s'émousse, poussez la rigueur dans des outils qui ne se fatiguent jamais : tests unitaires, vérifications de types, listes de contrôle en revue de code, scripts d'évaluation qui testent le code généré. Le filet de sécurité raté par le senior peut vivre dans le pipeline CI.
• Pratiquez volontairement, loin de la machine. Refaites une petite fonctionnalité à la main. Lisez du code l'IA éteinte. Travaillez en binôme avec un humain. Gardez une part de votre semaine où la réflexion est entièrement vôtre.
• Sentez la pression. Demandez-vous honnêtement, une fois par mois : que pourrais-je encore faire si l'IA disparaissait demain ? Si la réponse rétrécit, réduisez les instructions.

La friction était la leçon. Arrêtez de tout supprimer.

Les moments difficiles du code n'ont jamais été un bug de la fiche de poste. C'était le poste. La confusion, les mauvaises premières versions, l'heure passée à courir après un bug qui n'était qu'une ligne manquante — c'était le prix de la formation, payé en temps.

Le danger de l'IA n'est pas de vous rendre plus rapide. C'est de vous rendre plus rapide en supprimant les parties qui vous rendaient meilleur.

Ce qui vous remplace vraiment

Voici la vérité inconfortable. L'IA ne remplacera peut-être jamais un développeur. Mais un développeur qui a cessé de pratiquer, de lire attentivement et de penser dur — celui-là peut tout à fait être remplacé. Pas par une machine. Par une version de lui-même qui a gardé son tranchant.

L'auteur de l'article le disait clairement : vous ne perdez pas ce que vous avez déjà appris. Vous cessez d'y ajouter. Et une compétence qui cesse d'ajouter cesse de grandir, et une compétence qui cesse de grandir commence à mourir.

Le nommer est le premier pas

La panique « l'IA remplace les développeurs » est bruyante, et c'est la mauvaise conversation. La vraie conversation est plus silencieuse : votre code est écrit pour vous, et il est écrit trop bien pour que vous preniez la peine de regarder.

L'IA est un outil, et un bon outil. Mais chaque outil a un coût, et celui-ci se paie en attention. Utilisez-la. Profitez-en. Livrez plus vite. Ne la laissez simplement jamais lire le code à votre place.

Car les développeurs qui survivent à l'ère de l'IA ne sont pas ceux qui ont le plus utilisé l'IA. Ce sont ceux qui savent encore penser, et qui se sont assurés que l'outil ne penserait jamais à leur place.