Prompt Engineering

Le prompt engineering est la pratique qui consiste à formuler, structurer et tester les instructions envoyées à un modèle de langage pour en obtenir un résultat fiable et reproductible. Un prompt n'est rien d'autre que le texte de la demande, mais sa rédaction relève d'un travail de conception, pas d'une formule magique.

La comparaison la plus parlante est celle du briefing donné à un collaborateur compétent et rapide, mais qui ne connaît ni votre entreprise ni le contexte de la demande, et qui oublie tout entre deux échanges. Tout ce que vous ne dites pas, il le comble de façon plausible.

Ce que contient une instruction bien construite

• Un rôle et un objectif : qui parle, pour qui, dans quel but.
• Le contexte utile : les données, extraits ou documents sur lesquels s'appuyer, clairement séparés des consignes.
• Le format de sortie attendu : gabarit de texte, structure de données, longueur.
• Les contraintes et les interdits : ce qu'il ne faut pas inventer, et l'autorisation explicite de répondre qu'une information est absente.
• Un ou deux exemples de réponse correcte, qui valent souvent mieux qu'un paragraphe d'explication.

Ce que cela change concrètement

À modèle égal, l'écart entre une consigne vague et une consigne cadrée se lit directement dans le taux d'erreur. Pour l'extraction d'informations dans des courriels, la classification de demandes entrantes ou la rédaction sous contrainte, c'est le levier le moins cher et le plus immédiat : aucune infrastructure à modifier, un effet mesurable en quelques essais.

Les pièges de la pratique

Le premier est le prompt qui grossit sans fin, où chaque incident ajoute une phrase jusqu'à rendre l'ensemble contradictoire. Le deuxième est l'absence de jeu de test : on corrige un cas, on en casse trois, et personne ne s'en aperçoit. Le troisième est l'injection d'instructions, lorsque le texte d'un utilisateur ou d'un document se retrouve collé aux consignes et peut les détourner, ce qui impose de séparer nettement les deux et de ne jamais accorder de confiance au contenu reçu. Le quatrième est la dépendance à une version de modèle, un changement de version pouvant modifier le comportement sans prévenir.

Quand cela suffit, et quand il faut autre chose

Le prompt engineering traite les problèmes de formulation, pas les problèmes de connaissance. Si le modèle ignore vos documents, il faut les lui fournir par une recherche documentaire plutôt que réécrire l'instruction pour la dixième fois. Et si la règle à appliquer est déterministe, une condition écrite dans du code sera toujours plus fiable, plus rapide et moins chère qu'une demande adressée à un modèle.