Le prompt engineering se meurt — et nous le remplaçons par pire
Sculpter la requête parfaite ne sert bientôt plus à rien. Le réflexe qui prend sa place — sur-spécifier chaque étape — est, selon le créateur de Claude Code, une cause d'échec très courante.
Il y a un an, « prompt engineer » était un intitulé de poste que des entreprises s'arrachaient. Aujourd'hui, Boris Cherny — le créateur de Claude Code — décrit cette compétence comme étant en voie de disparition. Avec l'arrivée de modèles de pointe comme Opus 5, l'art de sculpter la requête parfaite devient largement obsolète.
Ce qui est intéressant n'est pas la nouvelle : c'est ce qui vient la remplacer. Parce que le réflexe de substitution n'est pas de lâcher du lest : c'est d'en rajouter. Cherny a un mot pour ça, la sur-ingénierie — l'over-engineering — et il en fait une cause d'échec très courante.
La compétence a changé de place, elle n'a pas disparu
Le prompt engineering classique consistait à chercher la formulation exacte qui déclenche le bon comportement. Un travail d'orfèvre sur la phrase.
Selon Cherny, la compétence clé s'est déplacée ailleurs : elle consiste désormais à confier au modèle une tâche difficile — voire une tâche qui semble un peu trop complexe pour lui — et à lui donner les outils nécessaires pour vérifier son propre travail de manière autonome.
Deux verbes, et aucun des deux ne concerne la formulation. Confier, puis outiller. Dans un contexte de code, ces outils de vérification n'ont rien d'exotique : un test qui passe ou échoue, un compilateur, un analyseur statique. Ce qui compte, c'est que le modèle puisse constater lui-même s'il a réussi, sans attendre qu'un humain relise chaque ligne.
Le piège de la sur-ingénierie, et ce sont les plus compétents qui y tombent
Cherny constate que les utilisateurs — et tout particulièrement les développeurs expérimentés — commettent souvent la même erreur : donner des instructions beaucoup trop spécifiques et séquentielles. Le fameux « fais l'étape 1, puis la 2, puis la 3 ».
Ce ne sont pas les débutants qui s'y cassent le nez. Ce sont ceux qui savent construire un système, décomposer un problème, écrire une spécification propre. Leur expérience se retourne contre eux.
L'explication tient en une phrase : les ingénieurs abordent l'IA avec les réflexes rigides qu'ils utilisaient pour coder des systèmes traditionnels. Là où le déterminisme était une vertu, il devient une contrainte inutile.
« Je pense que les gens ont tendance à trop y réfléchir et à faire de la sur-ingénierie parce que, d'une certaine manière, lorsque nous construisions des systèmes par le passé, c'est comme ça qu'il fallait faire. […] C'est une cause d'échec très, très courante que d'essayer de sur-spécifier […] et de vouloir que le modèle accomplisse la tâche exactement de la manière dont vous l'auriez fait, et ce n'est tout simplement pas comme ça que le modèle fonctionne. »
— Boris Cherny (traduit de l'anglais)
Un cap, des garde-fous, des critères de réussite
À la place de la séquence d'étapes, Cherny recommande trois choses.
Décrire la tâche à un niveau plus global. Pas le chemin, la destination. Ce que vous voulez obtenir, pas la manière dont vous l'auriez obtenu vous-même.
Indiquer les garde-fous. Ce que le modèle n'a pas le droit de faire, les zones à ne pas toucher, les contraintes non négociables. C'est là que se logent vos exigences réelles — bien plus que dans le découpage en étapes.
Définir les critères de réussite. À quoi ressemble un travail terminé et correct. C'est le pendant naturel des outils de vérification : sans critère explicite, un modèle qui peut tester son travail ne sait pas contre quoi le tester.
Puis laisser le modèle faire le travail.
Ce que j'en retiens, pour ceux d'entre nous qui construisons des automatisations : nous avons appris à spécifier des flux où chaque branche est prévue, parce qu'un scénario no-code, lui, exécute exactement ce qu'on lui a dessiné. Transposer ce réflexe à un modèle revient à lui retirer la seule chose qu'il apporte de plus qu'un automatisme — la capacité à trouver un chemin que nous n'avions pas prévu.
Désapprendre, puis traiter le modèle comme un collègue
La conclusion de Cherny est une invitation à désapprendre ces vieux réflexes et à adopter une démarche beaucoup plus empirique : traiter le modèle davantage comme un collègue de travail que comme un programme à diriger pas à pas.
L'analogie est éclairante parce qu'elle est vérifiable dans nos propres pratiques. À un collègue compétent, nous ne dictons pas chaque geste. Nous donnons le contexte, les contraintes, ce à quoi ressemble un résultat acceptable, et nous relisons ce qui revient. Le micro-management d'un collaborateur qualifié produit du travail médiocre et du ressentiment ; avec un modèle, il ne reste que le travail médiocre.
« Ce n'est plus une science théorique »
Cherny ne s'arrête pas au changement de méthode : il décrit un changement de nature. Son conseil est formulé sans détour — « oubliez tout ce que vous avez appris sur la théorie de l'informatique en cours ».
L'ingénierie logicielle traditionnelle repose sur la conception théorique et l'anticipation des architectures : on réfléchit d'abord, on construit ensuite. Travailler avec les modèles actuels demande l'inverse. Selon lui, le domaine « n'est plus une science théorique, c'est devenu une science empirique ».
Les meilleurs utilisateurs de l'IA sont, dans sa lecture, ceux qui parviennent à abandonner leurs anciens réflexes et leurs idées préconçues — leurs priors. La méthode qu'il préconise tient dans un cycle, et ce cycle n'a rien de théorique :
- donner une tâche au modèle pour le tester ;
- observer concrètement les résultats et repérer où il rencontre des difficultés ;
- ajuster son approche à partir de ces seules observations, au lieu d'essayer de tout paramétrer et d'anticiper à l'avance.
Si le modèle n'emprunte pas le chemin que nous aurions pris, le seul moyen de savoir ce qu'il sait faire est de le lui demander et de regarder — y compris, et surtout, sur les tâches qui semblent un peu trop difficiles pour lui.
Ce qui disparaît vraiment
Le prompt engineering ne meurt pas parce que la manière de parler aux modèles n'aurait plus d'importance. Il meurt parce que l'effort s'est déplacé : de la formulation vers le cadrage, du contrôle du chemin vers la vérification du résultat.
Ce n'est pas une compétence plus facile. C'est une compétence plus inconfortable, parce qu'elle demande de renoncer à savoir comment le travail a été fait pour ne juger que de ce qu'il vaut. Les ingénieurs ne sont pas les mieux armés pour ce renoncement — ils sont les moins bien armés, et c'est tout l'objet de la remarque de Cherny.
Et vous, quand une réponse d'IA vous déçoit, votre premier réflexe est-il d'ajouter des précisions au prompt — ou d'en retirer ?
La discussion continue sur LinkedIn — répondez sous le post d'origine. Source : interview vidéo de Boris Cherny (Anthropic), citations traduites de l'anglais.
Questions fréquentes
Le prompt engineering est-il vraiment mort ?
Boris Cherny le décrit comme une compétence en voie de disparition, rendue largement obsolète par des modèles de pointe comme Opus 5. Ce n'est pas la fin de toute méthode, mais un déplacement : la valeur ne réside plus dans la formulation exacte de la requête, elle réside dans le cadrage de la tâche et dans la vérification du résultat.
Qu'appelle-t-on la « sur-ingénierie » d'un prompt ?
C'est le fait de sur-spécifier : donner des instructions trop précises et séquentielles, du type « fais l'étape 1, puis la 2, puis la 3 », en voulant que le modèle accomplisse la tâche exactement comme on l'aurait fait soi-même. Cherny en fait une cause d'échec très courante, car ce n'est pas ainsi que le modèle fonctionne.
Pourquoi les développeurs expérimentés se trompent-ils le plus souvent ?
Parce qu'ils abordent l'IA avec les réflexes rigides qu'ils utilisaient pour construire des systèmes traditionnels, où tout devait effectivement être spécifié pas à pas. Cette habitude, qui était une qualité, devient un handicap face à un modèle qui trouve son propre chemin.
Que faut-il donner au modèle à la place d'une suite d'étapes ?
Trois éléments : une description de la tâche à un niveau plus global, les garde-fous à respecter, et les critères de réussite. Puis on laisse le modèle travailler. L'objectif est de décrire la destination et les limites, pas l'itinéraire.
Faut-il traiter une IA comme un collègue ?
C'est la formule de Cherny : traiter le modèle davantage comme un collègue de travail que comme un programme à diriger pas à pas. Concrètement, cela signifie confier une tâche difficile, fournir le contexte et les outils permettant de vérifier le travail, puis juger le résultat plutôt que la méthode.