Le prompt engineer a-t-il disparu, ou a-t-il changé de métier ?

Pourquoi écrire un bon prompt ne suffit plus

À ses débuts, l'art du prompt relevait de l'astuce : trouver la formulation qui débloque une réponse, ajouter un exemple, demander une méthode étape par étape. Ces techniques ont perdu de leur valeur à mesure que les modèles sont devenus plus robustes. Les instructions maladroites produisent désormais des résultats acceptables, et les outils d'optimisation automatique ajustent les formulations à la place de l'humain. Ce qui était un talent rare est devenu une compétence de base, comparable à savoir utiliser un moteur de recherche. Le simple rédacteur de prompts ne se distingue plus, et c'est ce déplacement qui nourrit le débat sur la fin du métier.

Cette banalisation ne signifie pas sa disparition, mais le déplacement de sa valeur. Écrire une instruction correcte n'impressionne plus personne ; concevoir un dispositif qui produit des résultats fiables, mesurables et sûrs, voilà ce qui se paie. Le marché ne rémunère plus le tour de passe-passe, il rémunère la rigueur et la capacité à tenir un résultat dans la durée. Les professionnels qui n'ont appris que des astuces se retrouvent sans avantage réel. Ceux qui ont compris l'évaluation, la structure et les limites des modèles continuent d'être recherchés. La compétence n'a pas disparu, elle s'est enfoncée d'un cran.

Du prompt isolé au système d'agents

La vraie bascule se joue dans le passage du prompt unique au système. On ne demande plus à un modèle de répondre à une question, mais à un ensemble d'agents de mener une tâche de bout en bout : chercher, trier, décider, rédiger, vérifier. Le travail consiste alors à découper le problème, définir les rôles, organiser les échanges et placer les contrôles. Ces systèmes demandent des instructions beaucoup plus élaborées, des règles de comportement, des formats de sortie stricts et des mécanismes de reprise en cas d'erreur. Le métier glisse progressivement du bricolage vers l'architecture logicielle, avec ses exigences propres.

Ce glissement rapproche le prompt engineer de l'ingénieur tout court. Il doit comprendre le cycle de vie d'un système, gérer les coûts d'appel aux modèles, prévoir les temps de réponse et assurer la reproductibilité des résultats. Il conçoit des tests pour vérifier qu'une modification d'instruction n'abîme pas les cas déjà fonctionnels, et documente les choix pour que d'autres puissent reprendre le travail. Cette rigueur tranche avec l'image d'improvisation qui collait au départ au métier. Devenir architecte de systèmes agentiques, c'est accepter que les prompts ne soient que la couche visible d'un édifice plus vaste, où la structure compte davantage que la formule.

La sécurité des instructions, spécialité montante

Une spécialité s'impose au-dessus des autres : la sécurité des instructions. Dès qu'un modèle lit du contenu extérieur — une page web, un courriel, un document — il s'expose à des injections qui détournent ses consignes. Un attaquant peut glisser une phrase dans un texte anodin pour lui faire exécuter une action non prévue. Protéger un système contre ces manipulations demande de comprendre ses canaux d'entrée, de cloisonner ses permissions et de tester sa résistance. Cette compétence, encore rare, se situe à la frontière de la sécurité informatique et de la conception de modèles.

S'y ajoute le contrôle des sorties : empêcher la fuite d'informations confidentielles, limiter les données personnelles divulguées, filtrer les contenus problématiques. Dans les secteurs régulés, ces exigences rejoignent les obligations de conformité et de protection des données. La personne qui maîtrise ces sujets devient un interlocuteur précieux, car elle sait tenir la performance et la sécurité ensemble, sans sacrifier l'une à l'autre. Beaucoup d'organisations cherchent aujourd'hui cette double compétence, encore peu répandue sur le marché, et la rémunèrent en conséquence. C'est là que le métier prend de la valeur.

Ce qui reste précieux dans le métier

Ce qui reste précieux tient à trois qualités. D'abord l'évaluation : savoir mesurer si une réponse est utile, et pas seulement plausible. Ensuite l'humilité technique : connaître les limites des modèles et ne pas leur demander ce qu'ils ne peuvent pas faire. Enfin la clarté : transformer une intention floue en consignes exploitables par une machine et lisibles par un humain. Ces qualités ne s'effacent pas avec les progrès des modèles ; elles deviennent au contraire plus rares à mesure que tout le monde sait écrire une instruction correcte.

Pour ceux qui s'intéressent à cette voie, l'itinéraire a changé. Apprendre des formules par cœur ne mène nulle part ; mieux vaut partir de l'usage, construire un petit système, le faire échouer, comprendre pourquoi, le sécuriser. La connaissance des frameworks d'orchestration aide, mais elle se périme vite ; la compréhension des principes — évaluation, cloisonnement, traçabilité — résiste au temps. Le métier survit donc à condition de changer à la fois de nom et de contenu. Il ne meurt pas, il se déplace vers ceux qui conçoivent des systèmes plutôt que des phrases.