Recrutement · July 29, 2026 · 10 min de lecture

Comment recruter un prompt engineer : testez, ne prenez pas sur parole

Comment recruter un prompt engineer en 2026 : si vous avez encore besoin du rôle, comment repérer un revendeur de templates, et la mise en situation qui révèle la vraie compétence.

← Fait partie de The five pillars of hiring: what assessments measure

Traitons d'abord la question gênante, car vous y pensez déjà : le prompt engineering est-il encore un vrai métier en 2026 ? C'est légitime. Le titre autonome a eu un arc étrange — sacré nouvelle carrière tendance, puis discrètement déclaré mort une fois que chaque ingénieur a appris à écrire un prompt convenable. Les deux points de vue sont faux. Ce guide s'adresse au responsable du recrutement ou au fondateur qui envisage un recrutement de prompt engineer et ne sait pas s'il poursuit une spécialité réelle ou un titre qui s'est à moitié fondu dans le travail de tout le monde. La version courte : les prompt engineers dédiés persistent là où la qualité du prompt est le produit — automatisation du support, systèmes de génération de contenu, instructions d'agents fonctionnant à grande échelle — et disparaissent là où c'est une compétence partagée que tout le monde porte. Le rôle existe parce que la qualité des résultats des modèles est devenue un levier qu'un spécialiste peut actionner de façon mesurable. Votre travail est de déterminer si ce levier compte suffisamment dans votre entreprise pour recruter quelqu'un pour le manœuvrer, puis de recruter quelqu'un qui peut vraiment le faire plutôt que quelqu'un qui a collecté un certificat.

Que fait réellement un prompt engineer ?

Un prompt engineer possède la couche d'instructions entre votre produit et le modèle — les prompts, les messages système et les instructions d'agents — et, chose cruciale, les ensembles d'évaluation qui prouvent que ces instructions fonctionnent. Le travail, c'est la mesure, pas la rédaction. Imaginez une vraie semaine plutôt qu'un fantasme de fiche de poste.

Un prompt engineer d'automatisation de support commence la semaine avec une plainte de l'équipe opérationnelle : l'assistant continue de promettre des remboursements qu'il devrait escalader. Il n'ouvre pas le prompt pour commencer à reformuler. Il extrait cinquante transcriptions où ça a mal tourné, les trie par type d'échec, et construit un petit ensemble de cas qui reproduit le problème. Puis il change une instruction, réexécute l'ensemble, et lit le diff — les promesses de remboursement ont-elles cessé, et quelque chose d'autre a-t-il discrètement cassé ? Plus tard, il traque la dérive de format dans un système de contenu : la mise à jour du modèle de la semaine dernière a transformé du JSON propre en JSON enveloppé dans des excuses bavard. À la fin de la semaine, il rédige des instructions d'agents suffisamment robustes pour qu'un appel d'outil malformé à deux heures du matin n'envoie pas l'agent dans une boucle. Le fil conducteur est une boucle : hypothèse, test, mesure, répétition. Quelqu'un qui ne peut pas vous montrer cette boucle ne fait pas le travail, quoi que dise son CV.

En avez-vous vraiment besoin ?

Soyez honnête avant de publier l'offre, car c'est le titre le plus susceptible d'être recruté sur la hype. La plupart des entreprises n'ont pas besoin d'un prompt engineer dédié. Si votre surface IA se résume à une ou deux fonctionnalités — un outil de résumé ici, un assistant de rédaction là — les prompts peuvent et doivent être possédés par les ingénieurs qui les ont construits ou un product manager avec une vraie AI fluency, en parallèle de leur autre travail. Créer un spécialiste pour surveiller dix prompts est une solution à la recherche d'un problème.

Le rôle mérite sa place quand la couche d'instructions devient large, centrale et conséquente. L'automatisation du support gérant des milliers de conversations, où une baisse de deux points de la qualité de résolution se traduit en désabonnement. Un système de contenu générant en volume, où la dérive est un risque pour la marque. Des instructions d'agents fonctionnant sans surveillance, où un mauvais cas limite coûte de l'argent plutôt qu'une simple nouvelle tentative. Le test n'est pas « utilisons-nous l'IA » — tout le monde le fait maintenant — mais « est-ce qu'une personne qui améliore la qualité des résultats de quelques points change une métrique métier qui compte pour nous ? » Si la qualité du prompt est véritablement le produit, recrutez le spécialiste. Si c'est une compétence partagée, recrutez plutôt pour l'AI fluency dans l'équipe et lisez nos articles complémentaires sur le recrutement d'un ingénieur IA ou d'un product manager IA — l'un de ceux-là est peut-être le rôle dont vous avez vraiment besoin.

Qu'est-ce qui distingue un vrai prompt engineer d'un revendeur de templates ?

C'est le pire problème d'imposteurs dans tout le paysage du recrutement IA, et je vais le nommer clairement. Le rôle attire deux espèces de prétendants : le collectionneur de certificats, qui a suivi six cours de « prompt engineering » et peut réciter des frameworks avec des acronymes ; et le revendeur de templates, dont le portfolio est une belle bibliothèque de prompts à copier-coller qui ont fonctionné une fois, pour quelque chose, quelque part. Aucun des deux ne peut faire le travail. Un template qui a produit un beau résultat lors d'une démo ne vous dit rien sur sa tenue sur cent vrais cas, ou sa survie à la prochaine version du modèle. Nous vendons l'évaluation des candidats pour vivre, donc prenez mon cadrage avec du recul — mais la logique tient indépendamment de qui la dit.

La vraie compétence est l'itération systématique, et elle ressemble plus à un scientifique qu'à un rédacteur :

• Itération basée sur des hypothèses — lit un échec, forme une théorie spécifique sur la raison pour laquelle il se produit, change une variable, et mesure. Pas de modification aléatoire jusqu'à ce que quelque chose passe.
• Construction d'ensembles d'évaluation — transforme « ça semble mieux » en un ensemble de cas avec des résultats attendus, pour que l'amélioration soit un chiffre plutôt qu'une impression. C'est le signal le plus fort de loin.
• Rédaction d'instructions qui survivent aux changements de modèle — sait qu'un prompt sur-ajusté au modèle d'aujourd'hui casse sur la prochaine version, et construit pour la robustesse plutôt que l'ingéniosité.
• Lecture rapide des modes de défaillance — distingue les hallucinations de la dérive de format d'un refus excessif, parce que le correctif pour chacun est différent.
• Connaissance des limites de la couche d'instructions — dit « c'est un problème de récupération, pas un problème de prompt » quand c'est vrai, au lieu de promettre qu'un prompt peut tout régler.

Le vocabulaire est le piège. N'importe qui peut apprendre à dire « few-shot » et « chain-of-thought ». Ce pour quoi vous recrutez, c'est la discipline en dessous — le même instinct de mesure que notre guide prompt engineering par rôle décrit dans les rôles praticiens, et qui se manifeste concrètement pour les ingénieurs dans prompt engineering pour les ingénieurs logiciels. Un candidat qui parle couramment mais ne peut pas vous montrer un ensemble de cas est un revendeur de templates avec un meilleur vocabulaire.

Comment tester ces compétences ?

Arrêtez de demander aux candidats de définir des termes et commencez à les observer travailler. L'exercice unique le plus prédictif est embarrassingly simple : donnez-leur un prompt médiocre et un ensemble de cas sur lesquels il échoue, puis regardez-les diagnostiquer et itérer. C'est le travail, compressé en une heure. Vous ne notez pas le prompt final — vous notez la boucle qui l'a produit.

Observez la séquence. Lisent-ils les cas défaillants avant de toucher au prompt, ou commencent-ils à reformuler par instinct ? Regroupent-ils les échecs par type — trois sont de la dérive de format, deux sont des hallucinations, un est un refus — ou les traitent-ils comme un fouillis indifférencié ? Changent-ils une chose et réexécutent-ils, ou font-ils cinq modifications à la fois et perdent trace de ce qui a aidé ? Par-dessus tout : demandent-ils, ou construisent-ils, un moyen de mesurer si le changement a fonctionné sur l'ensemble complet, pas seulement sur le cas qu'ils regardaient ? Le candidat qui dit « je veux exécuter ceci sur les vingt cas, pas juste regarder celui-là » vous a dit qu'il peut faire le travail. C'est un test de mise en situation professionnelle, et il surpasse n'importe quelle référence sur le CV.

Parce que le prompt engineering est intrinsèquement AI-native, vous devriez observer comment le candidat travaille avec le modèle directement, pas seulement s'il peut. Le prisme le plus clair est le Cadre 4D de l'AI fluency — Delegation, Description, Discernment, Diligence. Pour ce rôle, Discernment et Diligence ont le plus de poids : détecter que la réponse confiante du modèle est subtilement fausse, et vérifier qu'un changement a tenu avant de déclarer victoire. Faire l'exercice dans un AI Sandbox réaliste — où le modèle est vraiment disponible et vous observez le processus, pas seulement l'artefact — est là où se situe notre point de vue en tant que plateforme. Et si vous voulez comprendre à quoi ressemble le fort versus le faible pendant que vous regardez, comment évaluer l'AI fluency explique comment lire les signaux dans une évaluation générée par IA.

À quoi ressemble la boucle d'entretien ?

Gardez-la courte et centrée sur les preuves — les prompt engineers talentueux sont rares et recherchés, donc une boucle trop longue les perd. Quatre étapes suffisent :

• Un écran de compétences que chaque candidat passe dans les mêmes conditions : un petit exercice d'itération sur des cas défaillants, noté sur le processus. Cela remplace le tri par CV et élargit le vivier aux praticiens autodidactes, qui sont souvent les plus forts ici.
• Le test de mise en situation principal — l'exercice avec le prompt médiocre et les cas défaillants ci-dessus, effectué dans un sandbox réaliste avec le modèle disponible et le processus observé. C'est l'étape qui décide du recrutement.
• Un entretien structuré avec les mêmes questions et la même grille pour chaque candidat : comment ils ont construit un ensemble d'évaluation passé, un cas où une mise à jour de modèle a cassé leurs prompts et ce qu'ils ont fait, un cas qu'ils ont décidé n'être pas un problème de prompt du tout.
• Une conversation avec les parties prenantes pour les rôles qui en ont besoin — l'automatisation du support et les systèmes de contenu se situent à côté des équipes opérationnelles et de marque, donc sondez s'ils peuvent expliquer un arbitrage à un propriétaire non technique sans se cacher derrière le jargon.

Sur la grille d'évaluation, donnez plus de poids au processus qu'à la finition. Un candidat qui a atteint un bon prompt par chance devrait être noté en dessous de celui qui a atteint un prompt légèrement moins bon grâce à une boucle propre et reproductible — parce que le prochain trimestre, sur un problème que vous ne pouvez pas prévoir, c'est la boucle qui livre. C'est la même approche structurée et centrée sur les compétences que nous adoptons dans toute la série sur les rôles de l'ère IA ; la différence ici est que le comportement observable est la discipline de mesure plutôt que la conception de systèmes.

Rémunération et séniorité, sans fausse précision

Je ne citerai pas de chiffre, parce que le marché de ce rôle évolue trop vite pour qu'un chiffre soit honnête au moment où vous le liriez, et inventer une fourchette serait exactement le genre de fausse précision que cette série évite. Ce que je peux dire est qualitatif et durable. Parce qu'un prompt engineer fort mêle discipline de mesure et jugement produit, le rôle tend à se situer à côté d'une bande d'ingénierie mi-niveau à senior ou d'apprentissage automatique appliqué plutôt qu'au niveau débutant — la valeur réside dans le jugement, et le jugement n'est pas junior. La séniorité suit la portée : quelqu'un qui possède les prompts d'une seule fonctionnalité est un recrutement différent de quelqu'un qui possède la stratégie d'instructions d'agents pour une ligne de produits, et vous ne devriez pas les payer ou les cadrer de la même façon. Comparez par rapport à votre propre marché pour les rôles IA adjacents, et ancrez sur les compétences démontrées dans le test de mise en situation plutôt que sur les attentes déclarées d'un candidat ou sa collection de badges de cours.

Les 90 premiers jours : à quoi ressemble la réussite ?

Vous saurez dans un trimestre si le recrutement était le bon, et les signaux précoces sont comportementaux, pas héroïques. Dans le premier mois, un prompt engineer talentueux ne réécrit pas immédiatement tout — il construit ou hérite d'un ensemble d'évaluation, pour que chaque changement ultérieur puisse être mesuré par rapport à lui. Ce seul geste sépare les professionnels des bricoleurs. Au deuxième mois, il a livré une amélioration mesurable à un vrai prompt et peut vous dire l'avant et l'après par rapport à l'ensemble de cas, pas une histoire sur comment ça semble mieux maintenant. Au troisième mois, il a détecté au moins une régression silencieuse — une mise à jour de modèle qui a discrètement dégradé les résultats que personne d'autre n'avait remarqués jusqu'à ce que les chiffres bougent — et, idéalement, a mis en place un garde pour que la prochaine soit détectée automatiquement. L'anti-modèle à surveiller est le candidat qui passe 90 jours à produire une belle bibliothèque de prompts sans harnais d'évaluation en dessous : impressionnant à regarder, impossible à faire confiance, et exactement le mode de défaillance que vous essayiez de recruter pour éviter.

Les meilleurs prompt engineers ne sont pas ceux avec la formulation la plus astucieuse ou la bibliothèque de templates la plus complète. Ce sont ceux qui peuvent prendre « le résultat ne semble pas bon », le transformer en un ensemble de cas, et vous remettre une amélioration mesurable qui survit à la prochaine version du modèle. Recrutez pour cette boucle — et testez-la directement — ou vous continuerez à confondre un bon vocabulaire avec une vraie compétence.