L'IA ne tue pas les programmeurs. Elle efface l'échelle junior

L'IA ne tue pas les programmeurs. Elle efface l'échelle junior

Les gens continuent de demander si l'IA va éliminer les programmeurs dans cinq ans. Je pense que cette question a déjà un train de retard. Ce qu'il y a de plus laid se passe plus bas. Je reviens sans cesse à un scénario très cru du monde réel : une petite boîte logicielle staffait autrefois une application métier ordinaire avec un chef de produit, un designer, deux développeurs front-end, un développeur back-end et de la QA. Puis le patron a forcé les seniors à commencer à utiliser l'IA pour les parties ennuyeuses. Les modèles de base de données sortaient vite. Les points d'accès CRUD sortaient vite. Les pages de formulaires sortaient vite. Même les squelettes de tests sortaient vite. Une grosse tranche du travail junior a simplement disparu.

Et c'est précisément la partie que trop de gens refusent encore de dire clairement. L'IA n'est pas en train de tuer avant tout l'idée même de programmer. Elle attaque l'ancien terrain d'entraînement : les tableaux de bord d'administration, les outils internes, les interfaces de programmation standardisées, les interfaces saturées de formulaires, les bases de tests, la logique de migration et tous les tickets répétitifs qui étaient agaçants mais utiles parce qu'ils apprenaient aux gens comment fonctionnent les vrais systèmes. Dès que cette couche commence à se faire manger par l'IA, la profession ne disparaît pas du jour au lendemain. L'échelle, si.

L'ancien chemin du débutant n'a jamais eu rien de glamour

Personne n'est entré dans le logiciel en rêvant de construire des pages de paramètres de compte ou encore un tableau de bord interne de validation.

Mais c'est comme ça que beaucoup de gens ont appris.

Ils apprenaient en gérant :

  • des tickets ennuyeux
  • des corrections de bugs répétitives
  • des écrans CRUD
  • des règles de validation
  • la colle entre interfaces de programmation
  • des panneaux d'administration
  • du nettoyage de tests
  • de la doc que personne ne voulait toucher

Ce travail n'était pas impressionnant. Il restait précieux.

Il permettait aux débutants de faire des erreurs sur des choses gérables. Il leur donnait des répétitions. Il leur montrait à quel point le vrai logiciel est sale une fois qu'on sort des tutoriels.

C'est exactement pour ça que je pense que ce moment est si dangereux. L'IA frappe le plus fort la couche la moins glamour, et cette couche-là était le système d'apprentissage, que cela plaise ou non.

L'économie devient brutale très vite

Si ça bouge aussi vite, ce n'est pas parce que les modèles sont magiques. C'est parce que l'arithmétique est brutale.

Si un ingénieur senior peut obtenir, à partir d'une consigne, une première passe correcte pour :

  • un tableau de bord back-office
  • une série de points d'accès
  • un formulaire de permissions
  • un script de migration
  • une base de tests unitaires

dans le temps qu'il fallait autrefois à un développeur junior pour prendre ses marques, poser des questions et construire la première version à la main, le management ne voit pas un débat philosophique. Il voit une compression des coûts.

C'est pour ça que je n'achète pas la phrase rassurante selon laquelle « l'IA fait encore des erreurs ». Bien sûr qu'elle en fait. Ce n'est pas le seuil qui compte. Si la personne senior peut corriger la sortie IA plus vite qu'elle ne peut accompagner la personne junior à travers le même travail, le siège junior devient beaucoup plus difficile à défendre.

Voilà pourquoi les petites équipes ont soudain l'air encore plus petites

Je pense que beaucoup de gens ratent à quel point c'est déjà concret.

Prenez un projet très banal : un client veut une application web interne avec des formulaires, des rôles utilisateurs, du reporting et quelques intégrations. Il y a quelques années, cela voulait dire confier un morceau de l'implémentation à des juniors parce que le travail était prévisible et chronophage.

Aujourd'hui, la conversation change.

Au lieu de :

  • « laisse le junior construire les formulaires »
  • « laisse le junior monter la première version de l'interface de programmation »
  • « laisse le junior gérer la mise en place des tests »

cela devient :

  • « fais générer la première passe par le senior avec l'IA »
  • « relis la sécurité et la logique métier »
  • « livre plus vite avec moins de gens »

Ce n'est pas une théorie. C'est un changement de manière de travailler. Et quand la manière de travailler change comme ça, l'effectif change avec elle.

La profession survit. La voie débutante, elle, non

C'est cette distinction que j'aimerais voir plus souvent.

Il y aura toujours des engineers.

Il y aura toujours des bugs difficiles.

Il y aura toujours des intégrations moches, des failles de sécurité, des incidents de production, des problèmes de performance bizarres, des compromis d'architecture, des bugs de permissions et des règles métier qu'aucun modèle ne comprend proprement à partir d'un seul prompt.

Mais rien de tout cela ne protège l'ancienne voie débutante.

Ce qui était autrefois un terrain d'apprentissage ressemble désormais, depuis la chaise du manager, exactement à l'endroit où l'IA est censée faire économiser de l'argent en premier.

C'est pour ça que c'est beaucoup plus dur que la question « les programmeurs vont-ils disparaître ? »

Non, pas comme ça.

La version plus dure, c'est : les entreprises vont-elles encore payer des humains pour apprendre sur le travail que l'IA gère désormais suffisamment bien ?

Et cette réponse paraît bien plus mauvaise.

« Apprends juste l'IA » n'est pas une réponse complète

Je pense aussi qu'une bonne partie des conseils dans cet espace sont beaucoup trop faciles.

Oui, les nouveaux développeurs doivent apprendre les outils.

Oui, refuser d'utiliser l'IA est stupide.

Mais « utiliser l'IA » n'est pas un plan de carrière à lui seul.

Si tout ce que vous faites, c'est utiliser l'IA pour aller plus vite exactement sur la couche que le marché essaie déjà de dévaloriser, vous n'échappez pas au problème. Vous êtes assis dedans.

La valeur plus sûre monte d'un cran :

  • une décomposition plus nette des exigences
  • une pensée systémique
  • du jugement d'architecture
  • du débogage de bêtises générées
  • savoir quand du code a seulement l'air correct
  • comprendre comment la logique produit et métier s'emboîtent réellement

C'est une barre différente de « savoir écrire du code ».

Le risque de long terme, c'est l'effondrement du pipeline

C'est la partie dans laquelle, selon moi, les entreprises avancent en somnambules.

Les senior engineers n'apparaissent pas de nulle part. Ils viennent généralement d'années de travail plus petit, plus sale, plus répétitif, jusqu'à ce que la bibliothèque de schémas dans leur tête devienne assez riche pour porter des choses plus difficiles.

Si les entreprises vident cette couche trop agressivement parce que les économies à court terme ont l'air fantastiques, elles pourraient découvrir plus tard qu'elles ont économisé de l'argent en brûlant le chemin qui produisait autrefois leurs futurs seniors.

Ce type d'erreur me paraît tout à fait crédible.

Il collerait parfaitement au schéma :

  • célébrer l'efficacité maintenant
  • ignorer le problème de la formation
  • paniquer plus tard quand le marché sera rempli de gens qui ont utilisé des outils IA mais n'ont jamais construit de vrai jugement

Ce que je dirais à un nouveau développeur aujourd'hui

Si je commençais aujourd'hui, j'arrêterais de penser que le but est « devenir quelqu'un qui écrit du code ».

C'est trop petit.

Je viserais plutôt à devenir quelqu'un qui peut :

  • comprendre tout le système
  • repérer où le code généré est faible
  • suivre les bugs à travers les couches
  • raisonner sur les permissions et les états d'échec
  • transformer des demandes vagues en architecture exploitable
  • utiliser l'IA sans lui faire confiance aveuglément

Parce que le marché va payer moins pour la simple production brute de code qu'avant. Il va payer davantage pour la personne qui sait si cette sortie est sûre, complète et mérite d'être livrée.

Dernière pensée

Donc non, je ne pense pas que l'IA « tue simplement les programmeurs ».

Je pense qu'elle fait d'abord quelque chose de plus sale.

Elle creuse de l'intérieur le travail bon marché, répétitif et accessible aux débutants qui apprenait autrefois aux gens à devenir programmeurs.

C'est pour ça que le vrai combat ici, ce n'est pas l'IA contre l'ingénierie logicielle.

C'est l'IA contre l'échelle junior.

Et si cette échelle s'effondre, les dégâts n'apparaîtront pas seulement dans les chiffres de recrutement de cette année. Ils apparaîtront quelques années plus tard, quand tout le monde se rendra soudain compte à quel point il est devenu difficile de trouver des gens avec un vrai jugement.