Développeur logiciel junior

Les développeurs de logiciels système se classent 7e par les effectifs dans le quintile le plus exposé de l'annexe de l'article, et le développement logiciel est l'un des deux métiers que les auteurs isolent pour une étude de cas. Registres de paie du secteur privé américain fournis par ADP, couvrant des millions de salariés, de novembre 2022 à juin 2026. La baisse de 11 % concerne les 22-25 ans dans les deux quintiles les plus exposés à l'IA ; la même tranche d'âge dans les trois quintiles les moins exposés a progressé d'environ 10 %. Les salariés expérimentés ne montrent pas d'écart comparable, et les auteurs déclarent ne trouver aucune preuve d'une éviction généralisée à l'échelle de l'économie. Les résultats sont descriptifs, non causaux, et mesurés au niveau du métier, non de la tâche.

Changement vérifiable dans le recrutement, les effectifs, les heures ou le périmètre du poste. Le poids le plus fort — mais l'attribution causale reste à argumenter, pas à présumer.

Un recensement fait en vertu d'une obligation légale : les mêmes 20 questions posées à chaque organisme déclarant, chacune répondue par O ou N, avec le produit nommé et les licences données par tranches. « Générer du code avec l'IA » est à O pour 31 organismes sur 45, et les produits nommés n'existaient pas il y a trois ans. Un O est l'employeur qui déclare avoir l'outil, pas une mesure de la quantité de code qu'il écrit ni de ce qui en est conservé, et une tranche de licences n'est pas un décompte de personnes qui écrivent du code avec. La question ne distingue pas un ingénieur de dix ans d'expérience d'un ingénieur de dix mois ; ce relevé est rattaché ici parce qu'écrire du code courant — endpoints CRUD, formulaires, intégrations standard, tests de schémas connus — est exactement cette tâche, et non parce que l'inventaire dirait quoi que ce soit des développeurs juniors.

Un employeur l'a mis en production. Cela peut déplacer la ligne de base — pondéré par l'échelle et par la ressemblance du cadre avec le vôtre.

Une norme d'ingénierie qui s'impose aux équipes logicielles du Home Office (le ministère de l'Intérieur britannique). Elle dit que les équipes devraient utiliser l'IA là où elle aide, que les sorties assistées par IA doivent être relues et approuvées par un humain avant d'arriver en production et doivent être traçables, et que les équipes continueront de répondre pleinement de tout code et de toute sortie assistés par IA, parce que les outils d'IA ne peuvent remplacer ni le jugement, ni la compréhension, ni la maîtrise, ni la responsabilité humains à l'égard des décisions, des conceptions ou des modifications apportées aux systèmes. L'obligation ferme, « must », porte sur la relecture humaine ; la phrase sur la conception énonce qui en répond. Elle s'impose aux ingénieurs d'un seul ministère.

Un échec, un retour en arrière, une réglementation ou un coût freine l'adoption. Cela peut abaisser une appréciation ou élargir son incertitude.

Une étude universitaire sur des modèles de langage rédigeant des spécifications d'exigences pour un projet d'un cabinet de conseil informatique, évaluées par l'analyste expert du cabinet. Une partie des user stories est restée non traitée par tous les modèles, parce que la connaissance que détiennent les analystes peut être tacite et absente des documents de recueil des exigences ; l'analyste a estimé le gain de temps de rédaction entre 10 % et 15 %, et les auteurs concluent que les modèles peuvent aider la documentation initiale mais ne peuvent pas remplacer l'intervention humaine. C'est un projet avec un expert, et le rôle étudié est celui d'analyste des exigences plutôt que de développeur.

Essai à petite échelle dans un cadre réel. Cela nous dit que les conditions de déploiement sont mises à l'épreuve, non qu'elles sont réunies — donc un pilote ne suffit jamais à lui seul ; deux indépendants suffisent.

Une grande entreprise technologique, chiffre rapporté par elle-même, sans définition de la mesure de « produit » (autocomplétion contre fonctions entières). Ne dit rien du recrutement ; l'étape de relecture est restée aux ingénieurs.

Un employeur l'a mis en production. Cela peut déplacer la ligne de base — pondéré par l'échelle et par la ressemblance du cadre avec le vôtre.

Des ingénieurs de Google décrivant leur propre outillage interne. Google a affecté au hasard 50 % de tous ses développeurs à la réception, dans l'IDE, de correctifs suggérés par apprentissage automatique pour les builds cassés, et les a comparés aux autres pendant 11 semaines ; ensuite, environ 34 % des utilisateurs confrontés à un build cassé au cours d'un mois appliquaient ces correctifs, et la réparation de builds par apprentissage automatique a été activée pour tous les développeurs de Google. Le développeur prévisualise chaque correctif et choisit de l'accepter ou de le rejeter. Il s'agit d'erreurs de build et de compilation — celles que le billet qualifie de bien comprises — et non de défaillances à l'exécution dont la cause est loin du symptôme ; Google vend des outils d'IA pour développeurs.

Un employeur l'a mis en production. Cela peut déplacer la ligne de base — pondéré par l'échelle et par la ressemblance du cadre avec le vôtre.

Ce métier présente la coupure la plus nette entre l'entrée et le senior de tout le premier lot. Les tâches qui rendaient les postes juniors économiquement dignes d'être créés sont celles qui s'automatisent, tandis que celles qui définissent le travail senior ne le sont pas. Le risque n'est pas que la programmation cesse d'être un métier — c'est que le premier barreau de l'échelle soit retiré alors que le haut est intact. Concrètement : il vous faut démontrer du jugement, non du débit, et le faire avant que quiconque ne l'attende normalement de vous.

Votre position est relativement forte, mais elle dépend d'un flux de gens qui ont appris le jugement à l'ancienne. Si le barreau d'entrée reste cassé, la contrainte qui arrive dans quelques années n'est pas l'automatisation — c'est que personne n'aura bâti l'expérience nécessaire pour relire ce que les outils produisent. Cela mérite d'être pensé comme une question de recrutement et de tutorat maintenant plutôt que plus tard.

Rester et se renforcer

Construisez du jugement plus vite que l'échelle ne l'attend

La denrée rare est quelqu'un capable de dire si un code généré est juste. Vous pouvez commencer à le démontrer dès le premier jour au lieu d'attendre deux ans.

Refaçonner le poste

Spécialisez-vous là où l'exactitude coûte cher

Paiements, sécurité, intégrité des données, infrastructure — les domaines où une réponse fausse énoncée avec assurance coûte de l'argent réel gardent fermement les humains dans la boucle.

Mouvement latéral

Les postes entre l'ingénierie et le problème

Ingénierie de solutions, expérience développeur, produit technique — des métiers où la valeur est de comprendre à la fois le système et ce que quelqu'un en attend.

Changement de secteur

Appliquez la pensée de l'ingénieur dans un domaine non logiciel

Beaucoup de secteurs n'ont presque personne capable à la fois de comprendre leur domaine et de construire. Cette combinaison est rare et ne concurrence pas la génération.

Oui, mais pour une autre raison qu'il y a cinq ans. Apprendre à coder servait à pouvoir produire du code. Aujourd'hui la valeur est de pouvoir le juger — et on ne peut pas juger un code qu'on n'aurait pas pu écrire. La formation fonctionne toujours ; ce qui a changé, c'est que le marché des postes d'entrée ne vous paie plus de façon fiable pendant que vous acquérez ce jugement. Prévoyez explicitement ce trou plutôt que de supposer que le premier emploi vous enseignera.

La raison économique de l'existence de ces postes — un débit bon marché sur du travail bien spécifié — s'affaiblit, et c'est un vrai changement structurel plutôt qu'un cycle. Mais les équipes qui cessent entièrement de recruter des juniors se créent un problème : dans quelques années, elles n'auront personne qui a appris à juger une production à la dure. Attendez-vous à ce que le poste soit redéfini autour de la relecture et du jugement plutôt que de la production, et en moins grand nombre par équipe qu'avant.

Le signal pour les développeurs débutants n'est pas la capacité des modèles, c'est le recrutement de jeunes diplômés chez votre employeur. Regardez combien de juniors votre entreprise a recrutés cette année par rapport à il y a deux ans. Plusieurs organisations ayant coupé ce recrutement ont publiquement dit avoir supprimé la voie qui produit les seniors — cet aveu est l'événement à suivre.

Écrire du code de routine — la tâche marquée comme en cours d'automatisation, et celle qui remplissait les deux premières années d'un junior. La conception de système et les spécifications ne le sont pas, mais c'est là qu'on arrive après ces deux ans, et rien n'a remplacé la route.

Oui, et pour une raison qui a changé : vous apprenez désormais à coder pour relire du code, non pour en produire. Bien relire une production fluide mais fausse exige d'avoir écrit soi-même la même chose, ce qui veut dire que l'apprentissage doit encore se faire lentement même si le marché de la production s'est réduit.