Prompt engineering en entreprise : les bases pour de bons résultats

Faites l'expérience. Demandez à un assistant IA « écris un mail de relance à un client en retard de paiement ». Vous obtenez un texte poli, générique, qui pourrait s'adresser à n'importe qui. Utilisable, à peine.

Maintenant reprenez, mais dites-lui qui vous êtes, à qui vous écrivez, depuis combien de temps la facture traîne, le ton que vous voulez tenir et la longueur attendue. La réponse change de nature. Elle devient la vôtre.

C'est ça, le cœur du prompt engineering. Rien de magique. Une question de méthode.

Pourquoi la même IA rend un travail médiocre ou excellent

Un modèle de langage, comme Claude d'Anthropic ou les modèles d'OpenAI, ne devine pas votre contexte. Il ne connaît ni votre entreprise, ni votre client, ni la règle interne que tout le monde chez vous applique sans y penser. Il travaille avec ce que vous lui donnez, point.

Quand vous lui posez une question floue, il comble les trous avec ce qui est le plus banal, le plus probable, le plus lissé. C'est mécanique. Il vous rend une moyenne du web. Et une moyenne du web, sur un sujet qui vous est propre, c'est presque toujours à côté.

À l'inverse, plus vous cadrez la demande, moins il improvise. Vous ne le rendez pas « plus intelligent ». Vous réduisez le nombre de directions dans lesquelles il peut partir. C'est là toute la bascule : un bon prompt ne muscle pas le modèle, il rétrécit son terrain de jeu jusqu'à ce qu'il ne reste qu'une bonne réponse possible.

Ce constat vaut pour un mail rédigé à la va-vite un mardi soir. Il vaut mille fois plus quand ce même prompt tourne cent fois par jour dans une automatisation, sans personne pour relire chaque sortie.

Les cinq briques d'un bon prompt

On peut résumer une consigne solide à cinq ingrédients. Aucun n'est obligatoire à chaque fois. Mais quand un résultat vous déçoit, c'est presque toujours qu'il en manque un.

1. Le contexte

Dites au modèle dans quel monde il travaille. Qui parle, à qui, pourquoi, dans quelle situation. « Tu traites les mails entrants d'une PME de mécanique de précision. Les expéditeurs sont des clients ou des fournisseurs. Certains passent commande, d'autres réclament un délai, d'autres se plaignent d'une pièce non conforme. »

Sans ce cadre, le modèle traite votre demande hors-sol. Avec, il commence déjà à trier. Le contexte, c'est ce qui transforme une question générale en une question qui ne pouvait venir que de chez vous.

2. Le rôle

Assigner un rôle oriente le vocabulaire, le niveau de détail, la posture. « Tu es un assistant comptable rigoureux » ne produit pas le même texte que « tu es un commercial chaleureux ». Le premier va compter, vérifier, rester factuel. Le second va soigner la relation.

Ce n'est pas du folklore. Un rôle bien choisi active la bonne manière de répondre. Pour de l'extraction de données sur une facture, on demande de la précision froide. Pour une réponse client, de la mesure et du tact. Précisez lequel des deux vous voulez, sinon le modèle choisit à votre place.

3. Les exemples

Voilà la brique la plus sous-estimée, et souvent la plus puissante. Montrer vaut mieux qu'expliquer. Donnez-lui deux ou trois exemples de ce que vous attendez, avec l'entrée et la sortie idéale côte à côte, et il calque. Un mail type déjà validé par vous, une fiche produit bien remplie, un classement de dossier fait comme il faut.

Cette approche a un nom dans le métier : le few-shot, quelques exemples glissés dans la consigne. En production, c'est décisif. Trois vrais exemples issus de vos archives valent mieux qu'un paragraphe d'instructions abstraites. Le modèle attrape votre style, vos formulations maison, vos petites règles implicites, sans que vous ayez à les écrire une par une.

4. Le format de sortie attendu

Si vous ne dites rien, le modèle vous répond en paragraphes bavards. Souvent, ce n'est pas ce dont vous avez besoin. Vous voulez peut-être un tableau, une liste à puces, un objet de mail plus un corps, ou des données structurées qu'un logiciel derrière saura relire.

Demandez-le explicitement. « Réponds uniquement avec le numéro de commande, la date et le montant, séparés par des points-virgules. » Dans une automatisation, ce point n'est pas cosmétique. Si l'étape suivante attend un format précis pour ranger l'info dans votre ERP, une réponse mal formatée casse toute la chaîne. Le format de sortie, c'est la prise entre le modèle et le reste de votre système d'information.

5. Les contraintes

Dernière brique : les garde-fous. Ce que le modèle ne doit surtout pas faire. « N'invente jamais un numéro de commande. Si l'information manque, écris "à vérifier" plutôt que de deviner. » « Ne dépasse pas 120 mots. » « N'engage aucun geste commercial, remise ou délai, sans validation humaine. »

Les contraintes sont ce qui vous protège du travers le plus connu de ces modèles : combler un vide avec une réponse plausible mais fausse. En clair, inventer avec aplomb. Une contrainte bien posée lui apprend à dire « je ne sais pas » plutôt qu'à broder. Sur un back-office où une erreur se paie, ça vaut de l'or.

Les erreurs qu'on voit revenir tout le temps

À force de regarder des prompts qui ne donnent pas ce qu'on attendait d'eux, les mêmes causes reviennent. En voici les plus fréquentes.

Empiler les demandes dans une seule phrase. « Résume ce document, traduis-le, sors-moi les chiffres clés et propose trois actions. » Le modèle fait tout, à moitié. Découpez. Une tâche par prompt, quitte à enchaîner. Vous y gagnez en qualité et vous repérez tout de suite quelle étape déraille.

Rester poli et vague. « Peux-tu m'aider à améliorer ce texte ? » Améliorer dans quel sens ? Plus court ? Plus formel ? Sans faute ? Le modèle n'est pas un collègue qui devine à demi-mot. Dites précisément le résultat visé.

Confondre longueur et clarté. Un prompt de trois pages n'est pas meilleur qu'un prompt de dix lignes bien pensées. Au contraire, trop d'instructions contradictoires noient le modèle. Chaque phrase de votre consigne doit gagner sa place.

Ne jamais donner d'exemple. On l'a dit, mais ça mérite d'être répété. La plupart des prompts médiocres pourraient être sauvés par deux exemples concrets. Les gens décrivent longuement ce qu'ils veulent au lieu de le montrer une fois.

Oublier de dire quoi faire en cas de doute. Sans consigne, face à une information manquante ou ambiguë, le modèle tranche seul. Souvent mal. Dites-lui toujours comment se comporter quand il n'est pas sûr. C'est la différence entre un outil qui vous alerte et un outil qui vous ment sans le savoir.

Un avant, un après, sur un cas de tous les jours

Prenons la relance d'un impayé, puisque tout le monde voit de quoi il s'agit. Voici ce que donne la version paresseuse.

« Écris un mail de relance pour une facture impayée. » Réponse : un texte tiède, « Cher client, nous nous permettons de revenir vers vous concernant votre facture en attente… ». Correct sur la forme, inutilisable en l'état. Aucun montant, aucune date, aucun ton assumé.

Maintenant la version cadrée. On donne le contexte : PME industrielle, deuxième relance, client habituel qu'on ne veut pas braquer. Le rôle : un gestionnaire de comptes clients ferme mais courtois. Les données : numéro de facture, montant, échéance dépassée de trois semaines. Le format : objet plus corps, moins de 130 mots. Les contraintes : pas de menace juridique à ce stade, proposer un règlement sous huit jours, ne jamais inventer de montant.

Le résultat n'a plus rien à voir. Un mail qui nomme la bonne facture, rappelle l'échéance sans agressivité, propose une échéance claire et se relit en dix secondes avant envoi. Le modèle est le même. La demande a changé de camp. C'est précisément ce genre de tâche qu'on automatise dans nos projets de relance d'impayés, avec un humain qui garde la main sur les dossiers délicats.

Bricoler dans ChatGPT ou intégrer un prompt de production

Ici, une ligne de partage sépare deux mondes qu'on confond souvent. Et cette confusion coûte cher.

D'un côté, l'usage interactif. Vous ouvrez ChatGPT ou l'application de Claude, vous tapez une demande, vous lisez la réponse, vous la corrigez, vous relancez. C'est un dialogue. Si la sortie est bancale, vous le voyez tout de suite et vous ajustez. L'humain est dans la boucle en permanence. Pour explorer, rédiger un premier jet, débroussailler une idée, c'est parfait, et tout le monde devrait s'y mettre.

De l'autre, l'usage intégré. Le même modèle, mais branché dans une automatisation qui tourne toute seule. Un mail arrive, un flux le récupère, envoie son contenu au modèle avec un prompt fixe, récupère la réponse et la range dans votre logiciel. Personne ne relit. Le prompt s'exécute cent fois, mille fois, sur des entrées que vous n'avez jamais vues à l'avance.

Ce n'est pas la même exigence. Dans le premier cas, un prompt approximatif suffit, vous rattrapez à la main. Dans le second, la moindre faiblesse se répète en série. Un prompt qui marche neuf fois sur dix a l'air très bien quand vous testez trois exemples. En production, sur mille passages, ça fait cent erreurs par jour, souvent silencieuses, qui polluent vos données sans crier gare.

C'est exactement pour ça qu'une bonne automatisation garde un humain sur les cas sensibles. Le modèle traite le volume, la personne valide ce qui engage. On développe ce principe dans notre article sur le partage des règles entre RPA et IA : l'IA propose, l'humain tranche là où l'erreur se paie.

Un prompt de production se versionne et se teste

Un prompt qui pilote une automatisation n'est pas un texte qu'on écrit une fois et qu'on oublie. C'est un composant. On le traite comme du code.

On le teste. Avant de le lancer en vrai, on le passe sur un lot de cas réels sortis de vos archives : les faciles, les tordus, les pièges. Le fournisseur qui écrit son numéro de commande à la main, la facture en photo floue, le mail à moitié en anglais. On regarde où le prompt tient et où il craque, et on corrige avant que ça touche vos vraies données. Un prompt qu'on n'a testé que sur trois exemples gentils n'est pas prêt.

On le versionne. Chaque évolution du prompt est datée, tracée, comparée à la précédente. Pourquoi ? Parce qu'un jour vous voudrez changer une consigne, et vous devez pouvoir revenir en arrière si la nouvelle version se comporte moins bien. Sans historique, vous bricolez à l'aveugle. Avec, vous savez exactement ce qui a bougé et quand.

On le surveille. Les modèles évoluent. Une nouvelle version d'un modèle peut suivre vos consignes un peu différemment. Vos fournisseurs changent leurs formats. Un cas jamais vu débarque. Un prompt qui tournait sans accroc peut se mettre à dériver. On garde donc un œil sur les sorties, avec des vérifications automatiques quand c'est possible et un contrôle humain sur un échantillon.

Cette rigueur ressemble à celle qu'on applique quand on connecte une IA à un ERP : entre le modèle et votre système, on ne laisse rien au hasard, chaque échange est cadré et vérifiable. C'est moins spectaculaire qu'une démo bluffante. C'est ce qui fait qu'un automate tient deux ans au lieu de se faire débrancher au premier couac.

À vrai dire, c'est souvent là que se joue la vraie valeur d'un prestataire. Écrire un prompt qui impressionne en réunion, beaucoup savent le faire. Écrire un prompt qui reste fiable dix mille fois de suite, sans surprise, c'est un autre métier. C'est le nôtre. On en parle plus largement sur notre page agence spécialisée en modèles de langage, et dans le contexte industriel sur l'agent IA en industrie.

Par où commencer, concrètement

Si vous débutez, inutile de viser la lune. Prenez une tâche répétitive, écrite, à faible risque. Un tri de mails, une première version de compte rendu, un résumé de document. Testez à la main dans l'interface, améliorez votre prompt avec les cinq briques, jusqu'à obtenir un résultat régulier.

Ce galop d'essai vous apprend deux choses. La valeur potentielle, d'abord : si le gain de temps est net sur cette tâche, il le sera à l'échelle. Et les limites, ensuite : vous verrez vite quels cas le modèle rate, donc où il faudra garder un humain.

Le passage du bricolage utile à l'automatisation fiable, lui, ne s'improvise pas. C'est le moment où on cadre, on teste, on versionne, on branche à vos outils. C'est le rôle de l'audit d'automatisation : repérer les tâches qui valent le coup, écarter celles qui ne s'y prêtent pas, et chiffrer honnêtement le reste.