L'ingénierie de prompt est-elle morte ? Les trois compétences que les programmeurs devraient vraiment cultiver en 2026

Ouverture : Le titre de poste très convoité il y a trois ans est désormais introuvable sur les sites d’emploi cette année

En 2023, Anthropic a publié une offre d’emploi pour un « Ingénieur en prompt », et la fourchette de salaires annoncée circulait avec force détails, soi-disant sans plafond, relayée pendant quinze jours par les médias technologiques mondiaux. Pendant ces quelques mois, les modèles de prompts sont devenus la discipline dominante : « méthode du jeu de rôle », « incantations de chaîne de pensée », « compilation de prompts magiques », les vendeurs de cours se sont enrichis en premier, et une grande foule a appris les modèles par cœur. Trois ans plus tard, sur le marché de l’emploi de 2026, le titre d’« Ingénieur en prompt » est presque introuvable — il n’a pas été renommé, il a disparu. Parallèlement, l’IA qui écrit du code, l’IA qui propose des solutions, l’IA qui fait des analyses ont intégré le flux de travail quotidien, le seuil d’entrée est si bas que même les stagiaires peuvent s’y mettre.

Ainsi, la vieille question a réapparu dans les commentaires sous un nouvel emballage : « Le cours de prompt pour lequel j’ai payé à l’époque a-t-il été appris pour rien ? », « Le poste n’existe plus, cette compétence est-elle toujours valide ? » Cette question pose le problème dans la mauvaise direction. La compétence n’a pas disparu, elle s’est dissoute — comme le sel dans la soupe, on ne le voit plus, mais le goût est entièrement là. Dans cet épisode, nous allons décortiquer cela : pourquoi l’ingénierie de prompt en tant que poste est morte, en quelles trois compétences elle s’est transformée, et vers quoi les programmeurs de 2026 devraient s’entraîner.

Shiwen : Le titre d’« Ingénieur en prompt » est froid depuis trois ans, quelle est votre première réaction — il aurait dû mourir depuis longtemps, ou est-ce une mort injustifiée ?

Yongliang : Il aurait dû mourir depuis longtemps, et pas injustement du tout. Mais précisons d’abord : ce qui meurt, c’est le « poste », pas la « compétence ». Il faut séparer les deux, sinon on arrive à des conclusions erronées comme « appris pour rien ».

Shiwen : Alors parlons-en clairement : pourquoi ce poste est condamné à mort, en quelles trois compétences il s’est transformé, comment s’exercer pour chacune, et que dois-je faire maintenant en tant qu’ingénieur ordinaire.

Q1 : Pourquoi le poste d’« Ingénieur en prompt » en tant que tel est-il voué à ne pas durer longtemps ?

Yongliang : Parce que ce n’a jamais été une profession indépendante, c’était un correctif temporaire à l’insuffisance des capacités des modèles.

Quand j’ai vu cette offre d’emploi en 2023, ma première réaction n’était pas l’envie, mais la curiosité : que fait cette personne une fois embauchée ? Chaque jour réfléchir à comment parler au modèle ? Le fossé protecteur de ce contenu de travail était trop peu profond. Les trois années qui ont suivi ont confirmé ce jugement. J’ai vraiment eu une telle personne dans mon équipe : recrutée en 2024 pour faire spécifiquement l’optimisation de prompts, elle faisait du bon travail, ses prompts étaient stables et réutilisables. Mais arrivé à la seconde moitié de 2025, son travail a commencé à s’amincir nettement — le modèle a changé deux générations, sa capacité de compréhension des instructions a augmenté, les incantations en trois parties soigneusement conçues auparavant, maintenant une simple phrase en langage clair suffit. Plus tard, il m’a dit lui-même : Directeur, mon travail principal maintenant consiste à vérifier si les prompts écrits par l’IA sont bons.

La raison technique de la disparition du poste n’est pas complexe : les premiers modèles étaient des systèmes qu’il fallait « coaxer », pour une même tâche, changer de formulation donnait une qualité de sortie aux antipodes, donc « savoir coaxer » est devenu une compétence. Mais chaque fois que les fabricants de modèles sortent une nouvelle version, ils vont dans la direction « sans besoin de coaxer » — renforcement du suivi des instructions, allongement de la fenêtre de contexte, stabilisation de l’appel d’outils. La direction du progrès des modèles est précisément la direction de la disparition de la compétence d’ingénierie de prompt. Le point final du progrès d’une compétence est son propre chômage, cela s’est produit plus d’une fois dans l’histoire du logiciel : les ingénieurs spécialisés dans la compatibilité des navigateurs, les ingénieurs spécialisés dans l’optimisation Flash, ont tous quitté la scène ainsi.

Donc ma conclusion est directe : l’ingénierie de prompt est morte de « ce n’était que de la traduction homme-machine ». La destinée de la profession de traducteur est d’être éliminée par les bilingues. Et quand chaque programmeur est forcé d’être bilingue — connaissant à la fois le métier et sachant se servir de l’IA — le traducteur à temps plein n’a plus de raison d’être. Ce n’est pas une tragédie, c’est la maturité de l’industrie.

Q2 : La première compétence à exercer est le jugement — de quoi s’agit-il exactement, comment l’exercer ?

Yongliang : Le jugement, c’est « savoir quoi demander à l’IA de faire », cela ressemble à une lapalissade, mais c’est en réalité la plus grande ligne de démarcation.

Ces dernières années où j’ai dirigé une équipe, j’ai observé un phénomène stable : avec le même ensemble d’outils IA, la production de deux personnes diffère d’un ordre de grandeur, l’écart réside presque entièrement dans la première phrase — quel problème vous lancez à l’IA. L’usage faible est de jeter un besoin grand et vide en entier : « Aide-moi à faire un système de suivi des patients ». L’IA fait aussi de son mieux, elle te sort une structure complète, quelque chose qui a l’air professionnel, mais le besoin qu’elle comprend et celui que tu veux vraiment, il y a neuf chances sur dix que ce ne soit pas la même chose. L’usage fort est de d’abord décomposer le problème en tâches aux limites claires : qui sont les objets du suivi, quelle est la condition de déclenchement, quelles étapes doivent être validées par un humain, d’où viennent les données et où elles vont, puis tout confier à l’IA une par une.

La capacité à décomposer le problème est essentiellement la compréhension des contraintes métier. Quand je recrute, je pose maintenant une question obligatoire : je te donne trois jours et un assistant IA, fais baisser le taux d’absence aux rendez-vous de consultation, que fais-tu en premier ? La plupart commencent à énumérer des moyens techniques, la réponse que je veux entendre est d’abord demander de clarifier : quelle est la définition d’une absence, où sont les données historiques, quelle baisse compte comme un succès, si changer les règles de rendez-vous va énerver les médecins. Ce sont les matières premières du jugement, l’IA ne peut pas te remplacer, car ces contraintes sont ancrées dans ton expérience de l’industrie.

Comment exercer le jugement ? J’ai établi une règle pour mon équipe : avant d’utiliser l’IA pour travailler, écris d’abord trois lignes — ce que je veux, ce que je ne veux pas, comment ça compte comme réussi. Écris, puis ouvre la boîte de dialogue. Cette habitude te force à finir de réfléchir avant d’appeler l’IA, et la réflexion elle-même sera amplifiée par le modèle, l’économie de réflexion sera aussi amplifiée par le modèle. Trois mois plus tard, en faisant le bilan, l’écart entre ceux qui écrivent les trois lignes et ceux qui n’écrivent pas est visible à l’œil nu. Pour faire simple, l’IA est une loupe, la loupe ne produit pas de jugement, elle ne fait qu’amplifier le peu que tu as déjà.

Q3 : La deuxième est la capacité de validation — voir si ce que l’IA livre est correct, est-ce que ça peut s’exercer ?

Yongliang : Ça peut s’exercer, et il faut l’exercer, car la façon dont l’IA se plante n’est pas le « faux à première vue » que s’imaginent les débutants, c’est « 80 % juste ».

C’est le point que je veux le plus souligner. Ce que l’IA livre, le plus dangereux n’est pas l’erreur évidente — l’erreur évidente tout le monde la voit, c’est quand elle a tort à 80 %, raison à 20 %, et que les 80 % de tort sont cachés dans les endroits qui ont l’air les plus professionnels. L’année dernière, sur un de nos projets, l’IA a généré un morceau de code traitant la réconciliation comptable de l’assurance maladie, la structure logique était belle, les commentaires étaient écrits plus normalement que ceux de mes ingénieurs seniors, lors de la revue ça a presque passé instantanément. Avant la mise en ligne, j’ai couru ma liste de validation comme d’habitude, il y avait une ligne « la direction de l’écriture de l’écart de réconciliation a-t-elle pris en compte le scénario de remboursement ». Vérification, erreur. L’IA avait écrit l’écriture selon la « direction d’encaissement », dans le scénario de remboursement la direction est toute inversée. Cette erreur, sans courir cette liste, même en revue dix fois on ne la verrait pas forcément, car chaque ligne est écrite « comme juste ».

La capacité de validation sert à prévenir cela. La liste de validation de mon équipe a maintenant plus de quarante points, classés par module : pour les données, vérifier les périmètres et les valeurs limites ; pour les interfaces, vérifier l’idempotence et les délais d’attente ; pour les processus, vérifier les branches d’exception et les chemins de retour en arrière. Derrière chaque point de liste, il y a un accident réel. La première chose pour les nouveaux employés n’est pas d’apprendre les normes de code, c’est d’apprendre cette liste par cœur, de lire les retours sur accidents. Au bout de six mois, leur immunité aux productions de l’IA est établie — ce n’est pas qu’ils ne font pas confiance à l’IA, c’est qu’ils savent où jeter un œil de plus.

Ce truc n’est pas mystérieux, c’est juste la conscience de qualité de l’ancien génie logiciel qui a changé de vêtements à l’ère de l’IA. Avant on validait le code écrit par des humains, maintenant on valide le code écrit par l’IA, les points de contrôle ont changé, l’exigence de sérieux du fond n’a pas changé. Avant on n’avait pas besoin de cette liste, parce que les endroits où les humains se trompent ont des motifs réguliers ; les endroits où l’IA se trompe sont plus aléatoires, donc la liste est encore plus importante.

Q4 : La troisième est la capacité de secours — pouvoir clore quand l’IA se plante, comment ça se manifeste au quotidien ?

Yongliang : La capacité de secours, c’est « quand l’accident arrive, peux-tu le contenir », c’est la seule des trois compétences qui ne peut pas être accélérée, qui ne se nourrit que d’accidents.

Racontons une histoire vraie. Au printemps de cette année, un module de rapports généré par l’IA a été mis en ligne, le soir même la tâche de synchronisation des données a écrasé un lot de champs des antécédents médicaux de patients historiques. L’alarme a sonné à vingt-trois heures et demie, l’ingénieur de garde a regardé pendant une demi-heure, a jugé que c’était le script de synchronisation incrémentielle généré par l’IA qui avait un comportement anormal dans des conditions limites — les données existantes avec une interruption de date n’ont pas été identifiées, et ont été considérées comme nouvelles et réécrites une fois. Le traitement s’est fait en plusieurs étapes : d’abord arrêter la tâche de synchronisation pour arrêter l’hémorragie, puis évaluer l’impact — combien de patients concernés, quels services ont des rapports pollués, si les données peuvent être annulées. Heureusement, on avait gardé une carte avant la mise en ligne, on avait fait un instantané complet avant la synchronisation, le retour en arrière a été fait en quarante minutes, le lendemain matin on a sortu le rapport d’accident au directeur du département d’information et à la direction de l’hôpital. De l’alarme à l’arrêt de l’hémorragie, en tout une heure cinquante.

Après coup, la rétrospective, la cause technique ne compte que pour 30 %, les 70 % restants sont humains : lors de la validation, personne n’a pensé à utiliser des données sales avec interruption de date pour tester le script de synchronisation — c’est l’aveuglement de validation dont on parlait en Q3 ; dans le processus de mise en ligne, il manquait l’étape de secours « double vérification le premier jour ». Depuis, tous nos modules générés par l’IA qui impliquent une écriture de données ont deux lignes forcées dans le processus de mise en ligne : double vérification le premier jour, et instantané complet. Ces deux lignes sont la concrétisation du secours : admettre que l’IA va se tromper, et répéter à l’avance « quoi faire si ça se trompe ».

Le cœur de la capacité de secours n’est pas la technique, c’est l’habitude mentale : supposer toujours que ça va casser, et que quand ça casse, tu es là. Quand je recrute, je demande toujours « quel est l’accident de production le plus grave que tu aies vécu », les candidats qui ne peuvent pas répondre, même avec une note technique élevée, j’hésite. Parce que ceux qui n’ont jamais marché dans un piège manquent de respect pour les productions de l’IA, et le respect est le point de départ de la capacité de secours.

Q5 : Le poste a disparu, la compétence s’est dissoute, comment un programmeur ordinaire doit-il s’exercer en 2026 ?

Yongliang : Exercez les trois ensemble, mais l’ordre compte : d’abord le jugement, puis la validation, le secours grandit naturellement avec les accidents.

Concrètement, quatre lignes actionnables. Première, transforme « écrire d’abord trois lignes » en mémoire musculaire : avant d’utiliser l’IA, écris clairement ce que je veux, ce que je ne veux pas, comment ça compte comme réussi. Cette étape exerce le jugement, le coût est le plus bas, l’effet est le plus rapide, la ligne de partage des eaux pour les nouveaux de mon équipe est là. Deuxième, construis-toi une liste de validation personnelle, ne copie pas celle des autres — chaque point doit correspondre à un piège que tu as toi-même rencontré. Commence à accumuler à partir de cinq points, en six mois arrive à vingt, tu seras la personne qui voit le plus juste les productions de l’IA dans l’équipe. Les endroits où l’IA se trompe ont une forte corrélation personnelle : les modules que tu utilises le plus, le métier dont tu es responsable, les pièges vont réapparaître.

Troisième, va volontairement chercher du travail qui a besoin de retour en arrière. Migration de données, basculement de système, tâches par lots, ces travaux ont une forte densité d’accidents, c’est le champ de bataille réel pour exercer la capacité de secours. N’aie pas peur de porter le chapeau, le chapeau porté devient un actif, la ligne la plus précieuse de mon CV n’est pas quel projet a réussi, c’est quel accident j’ai contenu. Quatrième, considère « apprendre à l’IA à travailler » comme une nouvelle compétence de base à écrire dans le quotidien : à chaque fin de tâche, prends dix minutes pour réfléchir à comment confier ce travail à l’IA la prochaine fois, comment vérifier si elle l’a fait correctement. Cette étape consiste en fait à intégrer l’héritage de l’ingénierie de prompt — comment exprimer clairement l’intention — dans le travail quotidien, le poste est mort, cette action vit au début et à la fin de chaque tâche.

Le point commun de ces trois exercices : rien ne coûte, pas de cours, pas de modèles, tout dépend de tremper dans les tâches réelles. En 2023, les gens qui achetaient des cours de modèles voulaient prendre des raccourcis, en 2026, ceux qui y voient clair savent que les raccourcis ont disparu — ce n’est pas une mauvaise nouvelle, cela signifie que la compétition redevient une compétition de compétences solides, et les compétences solides, tout le monde peut les exercer.

Épilogue

Shiwen : Pour finir, résumez cet épisode en une phrase ?

Yongliang : L’ingénierie de prompt n’est pas morte, elle a juste retiré le vêtement de « poste » pour devenir le jugement, la validation et le secours — avant on embauchait une personne pour coaxer l’IA, maintenant on exige que chacun soit capable de la coaxer, de la voir à travers, et de l’encaisser.

Shiwen : Cette phrase, je vous l’offre. À la prochaine.

---

[Approfondissement technique] Pourquoi les « modèles de prompt » ne peuvent pas vous sauver : Analyse des trois niveaux du point de vue de l’évolution des modèles

Dans cet épisode, nous avons répété que « la compétence s’est dissoute », pour les lecteurs techniques, décomposons pourquoi les modèles sont condamnés à l’échec, ce n’est pas de la métaphysique, c’est déterminé par la courbe de capacité des modèles.

Premier niveau : Le relèvement générationnel de la capacité de suivi des instructions. La compréhension des instructions des premiers modèles était probabiliste, changer de formulation et le résultat dérivait, l’essence des modèles était d’utiliser une expression à haute redondance pour compenser cette incertitude — « tu es un expert senior, s’il te plaît réfléchis étape par étape », ce genre d’incantation, c’était ajouter des contraintes au modèle, réduire l’espace de recherche. Mais à partir de la génération GPT-4, le suivi des instructions est passé de « besoin de coaxer » à « capable de comprendre le langage normal », chaque génération ultérieure renforce cette direction. Plus les contraintes sont stables, moins la redondance est utile, plus le cycle de vie du modèle est court. Les modèles qui valaient de l’or en 2023, en 2026 la plupart sont devenus des gestes rituels — inoffensifs, mais ne produisent plus de différence de qualité.

Deuxième niveau : L’ingénierie du contexte a remplacé l’ingénierie de prompt. Le facteur qui décide vraiment de la qualité de la production a migré de « comment dire cette phrase » à « si les matériaux donnés au modèle sont complets ». RAG, long contexte, fichiers de compétences, système de mémoire, tout ça, c’est une compétition de récupération et d’organisation, pas de formulation. Pour le même problème, lui donner des documents internes précis et des contrats d’interface, et demander en langage clair ; et ne rien donner, demander avec un modèle exquis, le premier gagne largement. C’est pourquoi le travail de l’ingénieur en prompt dédié s’est amaigri — la valeur a migré vers le côté contexte.

Troisième niveau : La validation et le secours sont devenus le nouveau champ de bataille principal de l’ingénierie. Quand le coût de génération tend vers zéro, le goulot d’étranglement passe de « comment générer du bon » à « comment identifier le mauvais ». Système d’évaluation, tests automatiques, scripts de réconciliation, plans de retour en arrière, tous ces rôles secondaires qui appartenaient avant à l’exploitation et à l’assurance qualité passent au premier plan à l’ère de l’IA. La limite supérieure de capacité IA d’une équipe ne dépend plus de l’intelligence du modèle, mais de la densité du pipeline de validation, de la rapidité du processus de secours. Cela revient à la conclusion de cet épisode : les trois nouvelles compétences correspondent à trois maillons d’ingénierie — le jugement correspond à la décomposition des tâches, la validation correspond au pipeline de qualité, le secours correspond aux plans d’exploitation. Le poste est mort, les maillons restent, et sont encore plus importants.