Une longue note publiée le 14 septembre 2026 sur seldo.com fait un pari à dix ans sur le métier de développeur. Son auteur - la copie dont nous disposons n'est pas signée dans le corps du texte, il s'y présente seulement comme travaillant dans l'évaluation de modèles d'IA - pose d'emblée les deux hypothèses sur lesquelles tout le reste repose, et nous dirons la même chose : si vous les refusez, la suite ne tient pas.
Hypothèse 1 : les agents vont absorber tout le cycle de vie du logiciel. Ils écrivent déjà bien le code et sont médiocres sur tout ce qui vient après - relire, tester, trouver et corriger les bugs, déployer, superviser, mettre à l'échelle. L'auteur parie que c'est temporaire, et qu'aucun obstacle structurel ne les en empêche. Hypothèse 2 : il n'y a pas de plafond à la quantité de logiciel dont nous avons besoin. Regardez le site de votre dentiste, de votre assurance, de l'école de vos enfants : ce logiciel n'est pas mauvais parce que personne ne sait faire mieux, il est mauvais parce que ceux qui en ont besoin ne peuvent pas payer mieux au prix actuel.
Ces deux hypothèses sont des paris, et l'article les assume comme tels. Ce qui suit, en revanche, est largement observable aujourd'hui.
Le marché du travail a déjà commencé à trancher
Les chiffres que la note rassemble dessinent un marché coupé en deux. L'équipe de Stanford qui suit l'emploi des jeunes dans les métiers exposés à l'IA mesure un écart de 19 % pour les 22-25 ans par rapport à leurs pairs moins exposés - contre 15 % un an plus tôt - et précise que cet écart se creuse par réduction des embauches, pas par licenciements. Côté entreprises, le rapport SignalFire 2026 donne un recrutement de débutants en baisse de 65 % depuis 2019 dans les grandes entreprises technologiques et de 75 % dans les jeunes pousses - pendant que la part de l'ingénierie dans les embauches monte, de 46 % à 55 %.
Traduction : on embauche moins de monde, mais une part plus grande de ceux qu'on embauche sont des ingénieurs. Simplement, pas le genre dont le métier principal est de taper du code.
Le détail le plus intéressant n'est pas le volume, c'est où ça se joue. Toujours selon les auteurs de Stanford, les jeunes perdent du terrain dans les métiers bâtis sur des connaissances écrites quelque part, et les expérimentés en gagnent dans ceux bâtis sur des connaissances qu'on acquiert en faisant le travail. Les chercheurs parlent de savoir codifié et de savoir tacite ; l'auteur de la note propose une reformulation plus crue : ce qui est dans les données d'entraînement, et ce qui n'y est pas.
Précision d'usage, et elle compte : ces chiffres sont cités d'après cette note, pas lus dans les rapports d'origine. Nous ne les avons pas vérifiés à la source.
Ce qui reste quand le code ne coûte plus rien
L'exercice central de l'article consiste à découper le coût de fabrication d'un logiciel et à demander, poste par poste, ce qu'un agent peut en prendre. Le résultat se range en quatre paquets : effondré (écrire le code) ; bientôt (relire, maintenir) ; le prochain sur la liste (mettre en production, mettre à l'échelle) ; et peut-être épargné - décider quoi construire, définir ce qu'est le « bon », rendre l'usage agréable.
Ce dernier paquet a une propriété que l'article formule bien : il ne se transfère pas. La définition du « bon » pour un agenda et celle pour un outil de planification, qui résolvent à peu près le même problème, n'ont presque rien en commun. Deux boulangeries n'ont pas non plus exactement le même problème. Chaque fois que vous rencontrez un logiciel avec mille options de configuration qui ne fait toujours pas ce dont vous avez besoin, vous touchez du doigt cette absence d'économie d'échelle.
À un certain niveau, tout logiciel est la formalisation d'un désir humain.
D'où l'argument qui tient tout : la seule personne au monde qui sait que le client tient une boulangerie et non une usine de pièces détachées, c'est le client. Ça ne s'extrait pas mécaniquement, ça ne s'entraîne pas dans un modèle, parce que ce n'est écrit nulle part. Quelqu'un doit aller le chercher, le transformer en quelque chose d'assez exact pour être construit, puis vérifier que ce qui a été construit correspond - ce qui n'est jamais le cas du premier coup.
C'est exactement le déplacement que nous décrivions en juillet à propos de la spécification comme nouvel actif logiciel. La note lui ajoute une conséquence économique : si le coût de création tombe à zéro, le goulot se déplace vers la description du problème, et il y reste.
Le marché a déjà mis un prix sur ce métier
Ce n'est pas une prospective : ce poste s'achète déjà, sous une douzaine de noms. Palantir avait inventé le forward deployed engineer - quelqu'un qui va s'asseoir chez le client, comprend ce dont il a réellement besoin, et le construit dans l'environnement du client, sous ses yeux. C'était une bizarrerie maison. En 2025, les offres pour ce titre augmentent d'environ 800 % en neuf mois ; au moment de l'écriture de la note, un recensement compte près d'un millier d'offres actives chez 462 entreprises, dont OpenAI, Anthropic, Databricks, Stripe et Google Cloud, Salesforce annonçant en vouloir un millier à elle seule.
La rémunération totale moyenne tourne autour de 240 000 dollars, les profils seniors dépassant 600 000. Autrement dit, c'est payé comme un poste d'ingénieur senior, parce que c'en est un. Le même métier s'affiche aussi comme solutions engineer, deployment engineer, applied AI engineer, implementation engineer - personne ne s'est encore mis d'accord sur le nom.
Lisez les fiches de poste et vous trouvez, en gros, un ingénieur produit senior : cadrer le problème avec le client, comprendre son métier, écrire du code de production dans des systèmes qu'on n'a pas construits, itérer jusqu'à ce que ça marche. Écrire du code y figure, mais c'est la plus petite part - et c'est la part que l'agent fait.
Le métier n'est pas neuf. C'est sa filière qui a disparu
L'article prend soin de rappeler que ce rôle n'est pas une invention de 2026. Quand les ordinateurs étaient neufs et les programmeurs rares, les entreprises employaient un analyste de systèmes : quelqu'un dont le métier entier consistait à s'asseoir entre l'entreprise et les programmeurs et à écrire le besoin assez précisément pour qu'on puisse le construire. Un mémo de l'université de Miami, en 1963, décrit déjà cette « nouvelle profession ». Puis le logiciel est devenu grand public, et ce traducteur est devenu un chef de produit - métier emprunté aux chefs de marque de Procter & Gamble, passé par Intuit puis Microsoft, où un programmeur nommé Jabe Blumenthal invente le program manager à la fin des années 1980 parce qu'Excel pour Mac avait besoin de quelqu'un pour décider ce que le produit devait faire.
Un métier et demi est ainsi devenu deux professions séparées pendant vingt-cinq ans. La thèse de la note est qu'elles sont en train de se refermer l'une sur l'autre.
Et c'est là que le raisonnement rencontre son vrai problème, celui qui donne son titre à cet article. L'industrie va avoir besoin, en quantité illimitée, de gens capables d'extraire un besoin d'un humain, de définir le « bon » et d'exercer un jugement - et nous ne fabriquons pas ces gens-là.
Les chiffres sont cruels. Le programme de chefs de produit débutants de Google, lancé en 2002 et copié partout depuis, prend une cinquantaine de personnes par an pour environ douze mille candidatures. Meta, Uber, LinkedIn, Salesforce et quelques autres font tourner des équivalents de taille comparable. Au total : peut-être quelques centaines de personnes formées chaque année, délibérément, à ce qui va devenir le cœur du métier - contre une filière de développeurs juniors qui se comptait en dizaines de milliers et qui est en train de s'éteindre.
Car l'ancienne filière n'était pas une école, c'était un effet de bord. On embauchait un junior pour écrire du code sur un ticket bien spécifié, un senior relisait, et en une décennie de ce régime le junior absorbait assez de jugement pour devenir senior à son tour. Les deux barreaux du bas de cette échelle - écrire le code, le faire relire - sont précisément les deux choses que les agents prennent. Les universités enseignent les structures de données, les formations intensives enseignent React ; personne n'enseigne « va passer une semaine chez un boulanger et reviens avec une spec ».
Ce qu'une organisation peut faire sans attendre dix ans
L'auteur pense que le marché finira par corriger : le prix de la ressource rare monte jusqu'à ce que quelqu'un trouve rentable d'en produire. Il cite IBM, qui redessine son poste d'entrée autour du contact client et de la spécification plutôt que de la frappe. Mais il ajoute que ça ira trop lentement, et qu'une génération sera abîmée entre-temps.
Une organisation n'a pas à attendre que le marché s'ajuste, parce que la transmission du jugement ne dépend pas d'un diplôme. Elle dépend d'une condition beaucoup plus prosaïque : que les décisions soient écrites quelque part. Le junior d'hier apprenait en regardant un senior arbitrer dans une revue de code. Si les revues de code disparaissent et qu'aucune autre trace ne prend le relais, il ne reste rien à regarder.
C'est très exactement ce que nous construisons, et je ne vais pas prétendre que c'est fortuit : Survol trace les décisions produit, les arbitrages d'une session et les contraintes appliquées, parce qu'un produit développé par des agents a besoin d'une source de vérité fonctionnelle. Mais l'effet de bord mérite d'être dit, parce qu'il répond à la question de la note : un arbitrage écrit, daté et rattaché à une fonctionnalité est un objet d'apprentissage. Une conversation avec un agent qui disparaît à la fermeture de l'onglet n'en est pas un.
Trois gestes découlent de là, et aucun ne demande d'attendre une réforme des universités :
- Écrire la décision, pas seulement le résultat. « On a choisi B » n'apprend rien. « On a choisi B parce que le client facture à la commande et pas à la ligne » s'apprend.
- Mettre les débutants au contact du besoin, pas du ticket. Si le barreau du bas de l'échelle n'est plus « écrire le code d'un ticket bien spécifié », il doit devenir « assister à l'entretien où le ticket se fabrique ».
- Mesurer ce qu'on refuse. Une organisation qui garde la trace des demandes qu'elle a écartées, et pourquoi, produit en un an un corpus de jugement que personne n'enseigne.
Le biais que l'auteur reconnaît, et qu'il faut garder en tête
Il y a dans cette note une honnêteté qu'on voit rarement, et qui mérite d'être reprise ici plutôt qu'enterrée. L'auteur écrit lui-même que « trouver quoi construire, pas comment le construire » est aussi la partie du métier qu'il a toujours préférée, et qu'il existe un travers bien connu : tout le monde, en parlant d'IA, conclut que tous les métiers seront automatisés sauf le sien, mystérieusement inautomatisable. Il demande qu'on le lise avec cette réserve. Nous la reprenons telle quelle - y compris pour nous, dont l'outil se trouve justement vendre le travail de spécification.
Il ne cache pas non plus ce que sa prévision coûte. Le métier d'écrire du code comme activité rémunérée est, selon lui, en grande partie terminé, et c'est une perte réelle - pas seulement pour les personnes, mais pour la profession, parce que c'est de cet artisanat que venait une bonne part du jugement dont il annonce la pénurie. Sa seule consolation tient en une observation : pour beaucoup de ceux qui croyaient aimer taper du code, ce qu'ils aimaient vraiment était le moment d'avant - celui où un problème confus prend soudain une forme précise. Ce moment-là, justement, devient le métier.
Sources
- « We are all Product Engineers now », seldo.com, 14 septembre 2026. La copie dont nous disposons n'est pas signée dans le corps du texte. Tous les chiffres de cet article en proviennent : les données de Stanford sur l'emploi des 22-25 ans, le rapport SignalFire 2026, le recensement des offres de forward deployed engineer et les effectifs du programme de chefs de produit débutants de Google y sont cités par l'auteur, et nous ne les avons pas lus dans leurs rapports d'origine. La note est en anglais : les passages cités ici entre guillemets sont traduits par nos soins.
