Qu'est-ce qu'un Prompt Engineer exactement ?

En bref

• Un prompt engineer conçoit les instructions qui guident le comportement des modèles d’IA — c’est la couche entre un LLM brut et un agent utile en production.
• Ce rôle mobilise autant la compréhension des processus métier que la connaissance technique des modèles de langage.
• La qualité des prompts conditionne directement la fiabilité d’un agent IA : une instruction mal construite produit des résultats incohérents, même avec un excellent modèle sous-jacent.
• Pour les PME, la question pratique n’est pas “faut-il du prompt engineering ?” mais “qui doit le faire et comment l’intégrer à l’implémentation ?”
• Le métier évolue vers l’orchestration de systèmes multi-agents, ce qui élève les exigences en matière de conception et de maintenance.

---

Ce que fait réellement un prompt engineer

Un prompt engineer est la personne qui traduit un besoin métier en instructions compréhensibles et exploitables par un modèle de langage. Ce n’est pas un développeur au sens classique : il n’écrit pas d’algorithmes déterministes. Il conçoit des instructions en langage naturel qui orientent un système probabiliste vers des comportements cohérents et utiles.

La distinction est importante. Un développeur définit exactement ce que fait un programme. Un prompt engineer guide ce que fait un modèle, en sachant que le résultat n’est jamais entièrement prévisible. Son travail consiste à réduire cette imprévisibilité autant que possible, pour que l’agent IA soit fiable en contexte de production.

Dans la pratique, cela couvre plusieurs activités : rédiger les instructions de base (le “system prompt”), tester les cas limites, identifier les comportements inattendus, itérer sur la formulation, et documenter les choix pour faciliter la maintenance. Sur un projet d’agent de qualification commerciale ou de traitement de documents, le prompt engineering représente une part substantielle du travail total.

Pourquoi ce rôle est apparu

Les LLMs comme Claude, GPT-4 ou les modèles accessibles via OpenRouter ont une capacité générale remarquable. Mais cette généralité est aussi leur limite dans un contexte métier : sans instructions précises, un modèle peut répondre de façon correcte dans l’absolu mais inutile dans le contexte spécifique d’une entreprise.

Un cabinet de recrutement qui déploie un agent de tri de candidatures ne veut pas une IA “généraliste”. Il veut une IA qui applique ses critères, utilise son vocabulaire, respecte ses procédures, et escalade au bon moment vers un consultant humain. Tout cela passe par le prompt.

L’émergence du prompt engineering comme discipline à part entière est directement liée à l’adoption des agents IA dans les entreprises. Tant que l’IA était utilisée ponctuellement pour générer du texte ou répondre à des questions simples, la qualité du prompt importait peu. Dès qu’on parle d’agents autonomes qui prennent des décisions, traitent des données clients, ou représentent l’entreprise dans une interaction, la rigueur de conception devient non négociable.

Les composantes d’un prompt bien construit

Un prompt efficace pour un usage commercial n’est pas une simple phrase. C’est une structure qui comprend plusieurs couches.

Le contexte et le rôle définissent qui est l’IA dans cet usage précis. Pas “tu es un assistant utile”, mais quelque chose comme : “Tu es un chargé de qualification pour une agence immobilière spécialisée dans l’investissement locatif. Tu interagis avec des propriétaires qui envisagent de confier un bien à la gestion. Ton objectif est de collecter les informations nécessaires à l’évaluation du dossier, pas de convaincre.”

Les règles comportementales précisent ce que l’IA doit faire et ne pas faire : quand transférer la conversation à un humain, comment répondre face à une objection, quels sujets éviter, quel ton adopter selon le profil de l’interlocuteur.

Les exemples et cas limites (ce qu’on appelle le “few-shot prompting”) montrent à l’IA, par des exemples concrets, comment traiter des situations spécifiques. C’est particulièrement utile pour les cas ambigus que le modèle ne peut pas résoudre à partir des instructions seules.

Les instructions de format indiquent comment structurer les réponses : longueur, style, structure des données en sortie, gestion des cas d’échec.

Chacune de ces couches interagit avec les autres. Modifier une règle comportementale peut avoir des effets sur le format de sortie. Ajouter un exemple peut involontairement biaiser le comportement sur des cas non couverts. C’est pour cette raison que le test systématique fait partie intégrante du travail.

Ce que le prompt engineering n’est pas

Quelques idées reçues méritent d’être corrigées.

Ce n’est pas du “jailbreaking” ou de la manipulation de modèles. Le prompt engineering professionnel vise à construire des comportements stables et prévisibles, pas à contourner des restrictions.

Ce n’est pas une compétence qu’on acquiert en regardant deux vidéos YouTube. La conception de prompts robustes pour un usage métier demande de comprendre comment fonctionnent les modèles de langage, de connaître les patterns d’échec courants, et d’avoir suffisamment de contexte métier pour anticiper les cas limites. Cela s’apprend par la pratique sur des projets réels.

Ce n’est pas une activité ponctuelle. Un prompt mis en production doit être maintenu. Les modèles sont mis à jour, les processus métier évoluent, les cas limites émergent en production. Un prompt engineering sans suivi produit des agents qui se dégradent progressivement.

Ce n’est pas non plus un substitut à l’architecture technique. Les prompts sont une couche de l’agent, pas l’agent entier. La gestion de la mémoire, les intégrations avec les outils, l’orchestration entre plusieurs agents — tout cela relève de l’architecture applicative. Un bon prompt dans un mauvais système reste un problème.

Les compétences d’un prompt engineer efficace

Le profil est hybride, et c’est précisément ce qui le rend difficile à trouver.

Du côté technique, il faut comprendre comment les modèles de langage traitent les tokens, comment la longueur et la position des instructions influencent les sorties, comment différents modèles réagissent différemment aux mêmes formulations, et comment les techniques comme le chain-of-thought ou le few-shot learning modifient le comportement.

Du côté métier, il faut être capable de faire une analyse de processus : cartographier les cas d’usage, identifier les scénarios critiques, comprendre les contraintes réglementaires ou relationnelles qui s’appliquent. Un prompt engineer qui ne comprend pas le métier de son client produira des instructions techniquement correctes mais commercialement inutiles.

La dimension rédactionnelle est souvent sous-estimée. La formulation précise a un impact direct sur le comportement du modèle. Un mot mal choisi peut introduire une ambiguïté que le modèle résoudra de façon systématiquement mauvaise. Cette précision langagière s’apprend et se teste.

Comment ça se passe sur un projet réel

Prenons un exemple concret : une agence de ressources humaines qui veut automatiser le premier contact avec les candidats après réception d’un CV.

La phase initiale consiste à documenter le processus actuel. Comment les consultants évaluent-ils un premier contact ? Quelles questions posent-ils systématiquement ? Quelles situations font l’objet d’un transfert immédiat à un humain ? Quels messages ne doivent jamais être envoyés automatiquement ?

Vient ensuite la conception des instructions : rôle de l’agent, critères d’évaluation, gestion des cas particuliers (candidat déjà dans la base, profil hors cible, CV incomplet, demande spécifique). Les premières versions sont volontairement simples.

La phase de test systématique couvre les cas nominaux mais surtout les cas limites. Que se passe-t-il si le candidat répond de façon agressive ? Si le CV est dans une langue non prévue ? Si le candidat pose une question sur la rémunération que l’agent ne doit pas traiter ? Chaque cas identifié génère soit un ajustement du prompt, soit une règle d’escalade.

Le déploiement se fait d’abord en parallèle du processus humain, pour comparer les sorties. Les ajustements post-déploiement sont souvent aussi importants que la conception initiale.

Dans notre travail d’accompagnement de PME sur des projets d’agents IA, chez Basalt Studio, le schéma qui revient le plus souvent est le suivant : la phase de conception est sous-estimée, la phase de test est bâclée faute de temps, et les problèmes apparaissent trois semaines après la mise en production quand les vrais cas limites commencent à se présenter.

Prompt engineering et systèmes multi-agents

L’évolution actuelle pousse au-delà du prompt engineering sur un agent isolé. Les architectures multi-agents, où plusieurs IA spécialisées collaborent pour traiter un flux de travail, introduisent une complexité supplémentaire.

Dans un système où un agent de qualification passe la main à un agent de prise de rendez-vous, lui-même connecté à un agent de préparation de dossier, les instructions de chaque composant doivent être cohérentes entre elles. Un changement dans le comportement d’un agent peut casser le fonctionnement d’un autre.

Cela implique une approche de conception plus systémique : définir des interfaces claires entre agents, standardiser les formats de données transmises, tester les transitions entre composants, et documenter les dépendances. Le prompt engineering au niveau d’un agent individuel reste la base, mais il doit s’inscrire dans une architecture plus large.

McKinsey et d’autres observateurs de l’industrie notent que les entreprises qui obtiennent les résultats les plus substantiels avec l’IA sont celles qui pensent en termes de workflows automatisés plutôt qu’en termes d’outils isolés. C’est précisément ce que les systèmes multi-agents permettent, à condition que la conception soit rigoureuse à chaque niveau.

Ce que les PME doivent retenir

Pour une PME de 20 à 150 personnes qui envisage de déployer des agents IA, le prompt engineering n’est pas une option à ajouter en fin de projet. C’est une activité centrale qui doit être planifiée, budgétée et confiée à quelqu’un qui sait ce qu’il fait.

Les questions pratiques à se poser :

• Qui fait le prompt engineering ? Un prestataire externe, un développeur interne qui se forme, ou un profil spécialisé recruté en interne ? Chaque option a un coût, un délai et un niveau de risque différents.
• Comment la maintenance est-elle organisée ? Un agent en production qui n’est jamais révisé se dégradera. Il faut prévoir un processus de suivi.
• Comment les prompts sont-ils documentés ? La documentation est souvent négligée, mais elle est indispensable dès qu’on passe à plusieurs agents ou qu’on change de prestataire.
• Comment mesure-t-on la performance ? Sans métriques définies (taux de transfert vers humain, taux de résolution, qualité des sorties), impossible de savoir si un agent fonctionne bien ou s’il dérive.

Les pièges courants

Quelques erreurs reviennent régulièrement dans les projets d’implémentation d’agents IA pour PME.

Trop d’instructions dans un seul prompt. Un prompt surchargé est difficile à maintenir et produit des comportements imprévisibles. Mieux vaut diviser en plusieurs agents spécialisés avec des instructions plus courtes et plus précises.

Aucun cas limite documenté. Les cas nominaux fonctionnent souvent bien. Les vrais problèmes viennent des situations non prévues. La phase de test doit être explicitement consacrée à chercher les cas où l’agent se comporte mal.

Instructions rédigées du point de vue du concepteur plutôt que du modèle. Ce qui est évident pour un humain familier du contexte ne l’est pas pour le modèle. Les instructions doivent être explicites, même sur ce qui semble aller de soi.

Absence de procédure d’escalade. Tout agent autonome doit avoir des conditions claires de transfert vers un humain. Un agent qui tente de tout gérer seul génère des erreurs graves dans les cas qui justement requièrent un jugement humain.

Confusion entre la qualité du modèle et la qualité du prompt. Changer de modèle ne résout pas un problème de prompt mal conçu. Et inversement, un excellent prompt ne compensera pas un modèle inadapté à la tâche.

---

Le prompt engineering est une discipline jeune mais déjà sérieuse. Les entreprises qui l’intègrent correctement à leurs projets d’IA obtiennent des agents qui tiennent la route en production. Celles qui le traitent comme un détail technique à régler en dernière minute se retrouvent à gérer des agents imprévisibles qui créent plus de travail qu’ils n’en économisent.

Si vous êtes en train d’évaluer un projet d’agent IA pour votre entreprise et que vous souhaitez discuter de la façon dont le prompt engineering s’intègre à une implémentation concrète, vous pouvez réserver un appel stratégie IA avec l’équipe Basalt Studio.