Prompting : compétence spécialisée ou compétence professionnelle de base ?

Deux discours qui empêchent de penser

Le premier discours a accompagné l'arrivée des modèles génératifs grand public : le prompting serait une discipline nouvelle, avec ses experts et ses recettes. Le second est arrivé en réaction, à mesure que les modèles devenaient plus tolérants aux formulations imparfaites : puisqu'il suffit désormais de demander normalement, le sujet n'existerait plus.

Les deux positions ont un point commun : elles parlent d'objets différents sans le dire. Écrire une demande claire à un assistant pour rédiger un compte rendu et concevoir l'instruction système d'un service qui traite des milliers de requêtes par jour ne relèvent pas de la même activité. La première est un usage. La seconde est une brique d'ingénierie. Les confondre produit des débats sans issue et, en entreprise, des attentes mal calibrées.

Cette analyse ne prédit ni l'essor ni la disparition d'un métier de Prompt Engineer. Elle décrit ce que recouvre concrètement le mot « prompting » selon le contexte, et où se situe la difficulté réelle.

Le prompting comme compétence professionnelle générale

Pour un professionnel qui utilise des systèmes IA dans son travail — analyse, rédaction, synthèse, exploration, préparation de décision — le prompting n'est pas une discipline. C'est une extension d'une compétence beaucoup plus ancienne : savoir formuler une demande. Ce qui distingue une utilisation efficace d'une utilisation frustrante tient à quelques comportements, tous transférables d'un outil à l'autre.

• Formuler clairement l'objectif : ce qu'on cherche à obtenir, et à quoi servira la sortie. Une demande sans finalité produit une réponse générique.
• Fournir le contexte utile : le matériau, le public visé, ce qui a déjà été essayé, ce qui est hors sujet. Le modèle ne connaît pas la situation.
• Expliciter les contraintes et le format attendu : longueur, ton, structure, niveau de détail, langue. Beaucoup de déceptions viennent d'un format implicite.
• Itérer plutôt que tout demander d'un coup : corriger, restreindre, demander une variante, faire expliciter un raisonnement quand c'est utile.
• Vérifier la réponse : recouper les faits, les chiffres, les citations, les références. Une sortie bien écrite n'est pas une sortie exacte.
• Savoir quand ne pas faire confiance au résultat : sujet où l'erreur coûte cher, information récente, domaine réglementé, absence de source vérifiable.

Ce niveau se transmet en quelques heures de pratique accompagnée. Il produit un gain réel et immédiat, et il ne justifie pas un intitulé de poste. En revanche, il commence à figurer implicitement dans beaucoup d'attentes professionnelles, au même titre qu'utiliser correctement un tableur ou un outil de recherche documentaire.

Le vrai marqueur de maturité : la vérification

La différence la plus visible entre deux utilisateurs ne se situe pas dans la formulation, mais dans ce qu'ils font de la réponse. L'un la reprend telle quelle ; l'autre sait quelles parties sont vérifiables, lesquelles ne le sont pas, et arrête l'usage quand l'incertitude dépasse ce que le contexte autorise. Ce jugement est une compétence professionnelle, pas une compétence technique.

Le prompting comme composant d'un produit IA

Le sujet change de nature dès que le prompt cesse d'être écrit par un humain pour lui-même et devient une pièce d'un système qui s'exécute automatiquement, pour des utilisateurs qui ne le voient pas et ne peuvent pas le corriger. Le prompt est alors du code : il a une interface, des dépendances, des versions, des effets de bord et des coûts.

• Templates et variables : le prompt est paramétré ; ce qui varie doit être identifié, échappé et contrôlé, y compris quand l'entrée vient de l'utilisateur.
• Instructions système : elles définissent le rôle, le périmètre, les interdits et le comportement en cas de doute. Elles sont souvent l'endroit où se joue la sécurité fonctionnelle.
• Contexte : que met-on dedans, d'où vient-il, comment est-il sélectionné, que fait-on quand il est trop long ou vide.
• Sorties structurées : un système en aval consomme la réponse ; il faut un format garanti, et un comportement défini quand le format n'est pas respecté.
• Tool use : quand le modèle peut déclencher des actions, la question devient celle des droits, de la réversibilité et de la validation humaine.
• Versionnage : un prompt modifié est un déploiement. Sans historique, personne ne peut expliquer pourquoi le comportement a changé.
• Évaluation et régressions : un jeu de cas rejoué à chaque changement, sinon toute amélioration locale se paie ailleurs sans qu'on le sache.
• Sécurité : entrées hostiles, tentatives de détournement d'instruction, fuite d'informations présentes dans le contexte.
• Coût et latence : la longueur du prompt et du contexte se paie à chaque appel, et se ressent à chaque interaction.

À ce niveau, la capacité à « écrire un bon prompt » est une compétence parmi une dizaine d'autres, et rarement la plus limitante. Ce qui bloque un système en production, ce sont généralement les données, l'évaluation, la gestion des cas limites et l'orchestration — pas l'élégance de la formulation.

Comparatif : prompt personnel et prompt de production

Prenons un même besoin : résumer une réclamation client pour préparer une réponse. La version personnelle et la version intégrée dans un produit n'ont pas les mêmes critères de qualité.

Le second n'est pas « le même prompt en mieux écrit ». C'est un composant logiciel dont le texte n'est qu'une partie. C'est précisément pour cela que la question « faut-il un spécialiste du prompting ? » n'a pas de réponse générale : elle dépend de la place du prompt dans le système.

Ce que l'évolution des modèles déplace réellement

Les générations récentes de modèles suivent mieux les instructions, tolèrent des formulations approximatives et demandent moins de contorsions. Une partie des techniques artisanales apparues au début — formules incantatoires, structures rigides, découpages complexes destinés à contourner des limitations — perd de son intérêt. C'est un fait observable, et il explique le second discours.

Mais cette érosion touche la couche la plus superficielle. Elle ne change rien à ce qui reste extérieur au modèle.

• Le cadrage : un modèle plus docile n'invente pas le problème à résoudre, ni le périmètre, ni les cas interdits.
• Le contexte : la qualité de ce qu'on fournit reste déterminante ; aucun modèle ne devine une information à laquelle il n'a pas accès.
• L'évaluation : savoir si une version est meilleure qu'une autre est un travail de mesure, indépendant de la génération du modèle.
• L'orchestration : enchaîner des étapes, appeler des outils, gérer les échecs et les reprises reste de l'ingénierie.
• Le contrôle : droits, traçabilité, comportement en cas de doute, place de la validation humaine.

Formulé autrement : les modèles absorbent progressivement les astuces, pas les responsabilités. Ce qui relève d'une décision — que doit faire le système, avec quelles données, jusqu'où, et comment le vérifie-t-on — ne se délègue pas au modèle.

Situer honnêtement sa propre pratique

Pour un professionnel, l'enjeu n'est pas de trancher un débat public, mais de savoir décrire son propre niveau sans surpromesse. Trois positions se distinguent nettement, et elles n'ouvrent pas les mêmes portes.

• Usage professionnel : j'utilise ces systèmes régulièrement dans mon travail, je sais formuler, itérer, vérifier et repérer les cas où je ne dois pas m'appuyer sur la sortie.
• Conception d'usage : j'ai construit des modes opératoires pour une équipe, défini ce qui peut être délégué au système et ce qui ne doit pas l'être, et accompagné l'adoption.
• Composant produit : j'ai contribué à des prompts intégrés dans un produit, avec évaluation, gestion des cas limites, versionnage et suivi du comportement en production.

Ces trois formulations sont vérifiables en entretien. « Expert en prompt engineering » ne l'est pas, et se retourne rapidement contre celui qui l'emploie. Décrire le niveau réel, avec le contexte et le résultat, est à la fois plus modeste et beaucoup plus solide.

• Prompting
• Culture IA
• Copilotes