Prompt engineering avec Claude : 10 bonnes pratiques

Le prompt engineering n'est pas de la magie : c'est une discipline. Avec un peu de méthode, on passe de réponses aléatoires à des résultats fiables et reproductibles. Voici les 10 pratiques que j'enseigne et que j'applique au quotidien avec Claude.

Qu'est-ce que le prompt engineering ?

Le prompt engineering est l'art de formuler des instructions à un modèle comme Claude pour obtenir des réponses fiables, précises et reproductibles. C'est une compétence clé pour tirer une valeur réelle de l'IA générative — au point de mériter une formation dédiée.

Les 10 bonnes pratiques

1. Donnez un rôle. « Tu es un analyste financier rigoureux » oriente le ton et la posture.
2. Fournissez le contexte. Le modèle ne connaît pas votre entreprise : donnez-lui les informations utiles.
3. Soyez explicite sur la tâche. Une instruction précise vaut mieux qu'une demande vague.
4. Montrez des exemples. Quelques exemples (few-shot) cadrent le résultat mieux qu'un long discours.
5. Imposez un format de sortie. JSON, tableau, liste : un format structuré devient exploitable par vos outils.
6. Demandez un raisonnement étape par étape pour les tâches complexes.
7. Fixez des limites. Dites au modèle quoi faire quand il ne sait pas (« réponds : information indisponible »).
8. Utilisez des balises pour séparer instructions, données et exemples — Claude les exploite bien.
9. Itérez avec des cas réels plutôt qu'avec des exemples jouets.
10. Versionnez et évaluez vos prompts comme du code, avec des tests.

Prompt et données : le rôle du RAG

Pour des réponses ancrées dans vos contenus, le prompt seul ne suffit pas : on lui adjoint le RAG, qui fournit à Claude les extraits pertinents de vos données au moment de la requête. Prompt + RAG, c'est la combinaison qui fiabilise les usages métier — voir l'intégration API Claude.

Un bon prompt dit à Claude comment penser ; le RAG lui dit avec quoi.

Viser la reproductibilité

En entreprise, on ne veut pas une bonne réponse une fois, mais des bonnes réponses à chaque fois. Cela suppose de traiter les prompts comme des artefacts d'ingénierie : versionnés, documentés, évalués sur un jeu de cas. La documentation Anthropic détaille de nombreuses techniques avancées.

Un exemple concret d'évolution d'un prompt

Pour illustrer la démarche : sur une mission de catégorisation automatique de demandes entrantes, le premier prompt rendait 78 % de catégorisations correctes. Après deux semaines d'itérations — ajout d'un rôle, de cinq exemples few-shot représentatifs des cas piégeux, d'un format JSON imposé pour la sortie, et d'une consigne explicite « si la demande ne rentre dans aucune catégorie, renvoie 'à reclasser' plutôt que de deviner » — on est passé à 94 % de catégorisations correctes, avec 4 % de cas explicitement marqués « à reclasser » et seulement 2 % d'erreurs silencieuses. La progression est venue de petits ajustements ciblés, pas d'un changement de modèle.

Trois erreurs typiques en prompt engineering

• Trop de contexte, mal trié. Empiler 20 pages dans le prompt sans les pré-filtrer noie l'information utile. Mieux vaut récupérer les 3 extraits pertinents via un RAG bien réglé et les fournir clairement.
• Confondre prompt et politique d'usage. Le prompt système définit le comportement du modèle ; il ne remplace pas un cadre d'usage défini avec le métier et la conformité. Les deux sont complémentaires.
• Ne pas versionner les prompts. Un prompt qui « marche » dont personne ne sait quelle version est en production est une bombe à retardement. Versionner les prompts comme du code permet de revenir en arrière, de comparer, de tracer.

Faire vivre le prompt engineering en équipe

Au-delà des techniques individuelles, ce qui distingue les organisations qui tirent vraiment parti du prompt engineering, c'est leur capacité à capitaliser collectivement. Cela passe concrètement par trois pratiques.

Une bibliothèque de prompts partagée et versionnée. Chaque équipe métier maintient ses prompts comme elle maintient ses procédures : avec un propriétaire, une date de dernière revue, un historique de versions. On évite ainsi le syndrome du « bon prompt perdu dans le Slack d'il y a six mois ».

Un format standardisé de documentation. Pour chaque prompt sérieux : son objectif, son périmètre d'usage, ses cas limites connus, ses évaluations, sa version courante. Une page d'une demi-page de documentation suffit, mais elle est indispensable pour la transmission entre collègues et pour les audits.

Une revue régulière des prompts critiques. Au même titre qu'on revoit régulièrement le code critique d'une application, on revoit les prompts qui pilotent des cas d'usage à enjeu. Avec les évolutions de modèles, un prompt qui fonctionnait il y a six mois peut avoir des comportements légèrement différents — la revue permet de les détecter avant qu'un utilisateur ne s'en rende compte en production.

Ces pratiques se mettent en place progressivement, à mesure que l'organisation prend confiance avec l'IA générative. Elles s'apprennent en formation et s'ancrent en mission de conseil.

Conclusion

Le prompt engineering est accessible, mais la maîtrise vient de la méthode et de l'évaluation. Ces 10 pratiques constituent une base solide ; le reste s'acquiert sur des cas réels. C'est précisément ce que je transmets en formation et ce que j'applique dans mes intégrations.

Envie de former vos équipes ? Voir la formation Claude ou contactez-moi.