Prompts Efficaces pour Claude, GPT et Gemini

Le mois dernier, j’ai passé trois semaines à réécrire la même requête six fois. La première version fonctionnait parfaitement avec Claude. Je l’ai transférée à GPT-4o et j’ai obtenu des résultats médiocres. Je suis passé à Gemini 2.0 et il a inventé des numéros de téléphone. Même instructions. Trois résultats différents.

Le problème n’était pas les prompts – c’est que j’écrivais pour le modèle, pas pour la tâche. Chaque LLM a des données d’entraînement différentes, des schémas de raisonnement différents et des comportements par défaut radicalement différents. Une fois que j’ai arrêté de penser à « un bon prompt » et que j’ai commencé à penser à « un prompt qui fonctionne pour ce modèle spécifique et cette tâche spécifique », les choses ont changé.

Il ne s’agit pas d’apprendre trois langages de prompt différents. Il s’agit de comprendre où ces modèles divergent, quelles techniques fonctionnent universellement et quels ajustements précis font la différence sur chacun d’eux.

Pourquoi le Même Prompt Échoue sur Différents Modèles

Claude (en particulier Claude Sonnet 3.5 et 4), GPT-4o et Gemini 2.0 ont été entraînés sur des données différentes, optimisés pour des objectifs différents et construits avec des choix architecturaux différents. Cela a un impact sur le prompting de manière spécifique et mesurable.

Claude a été entraîné avec Constitutional AI – une méthode qui met l’accent sur la réflexion et le raisonnement explicite. Vous remarquerez qu’il a tendance à montrer son travail, même lorsque vous ne le demandez pas. Il est également plus résistant aux jailbreaks et à l’exploitation des cas limites, ce qui signifie qu’il refuse parfois des requêtes raisonnables si elles sont formulées de manière à déclencher son entraînement à la sécurité.

GPT-4o a été entraîné pour être extrêmement généraliste et confiant. Il excelle dans le suivi d’instructions complexes et en plusieurs étapes. Il est également plus sujet aux hallucinations dans les scénarios où il manque de données d’entraînement – il inventera des informations plausibles plutôt que de dire « Je ne sais pas ». L’efficacité des tokens est meilleure que celle de Claude sur de nombreuses tâches.

Gemini 2.0 (sorti en décembre 2024) possède des capacités multimodales intégrées dès le départ, et il est entraîné sur des données plus récentes que Claude et GPT-4o. Il est agressif sur la fenêtre de contexte – prenant en charge jusqu’à 2 millions de tokens dans certaines configurations – mais il sous-performe parfois sur les tâches nécessitant un raisonnement intensif par rapport à Claude Sonnet 3.5.

Ce ne sont pas des défauts de conception. Ce sont des compromis. Et ils nécessitent des stratégies de prompt différentes.

Techniques Universelles Qui Fonctionnent sur les Trois

Tout ne nécessite pas d’être spécifique à un modèle. Quelques schémas fonctionnent sur Claude, GPT et Gemini – ils nécessitent simplement la bonne configuration.

Sortie Structurée avec Délimiteurs Clairs

Chaque LLM répond mieux lorsque vous définissez le format exact que vous souhaitez. Pas « résume ceci » – « renvoie un objet JSON avec les clés : résumé (chaîne), confiance (0-1), contexte_manquant (tableau). »

Voici à quoi cela ressemble en pratique :

## Mauvais prompt (trop ouvert)
Résumez cet article de recherche sur les hallucinations des LLM.

## Prompt amélioré (sortie structurée)
Lisez l'article de recherche ci-dessous. Retournez votre réponse sous forme de JSON valide avec ces clés exactes :
{
  "title": "titre exact de l'article",
  "core_finding": "1-2 phrases décrivant le résultat principal",
  "methodology": "comment ils ont mesuré les hallucinations",
  "confidence": "0.0 à 1.0 – votre confiance dans ce résumé",
  "cited_benchmarks": ["liste des benchmarks spécifiques mentionnés"]
}

Article :
[contenu de l'article]

Pourquoi cela fonctionne partout : la sortie structurée réduit l’ambiguïté. Claude honorera le format JSON car il est entraîné à le faire. GPT-4o aussi – il est optimisé pour la consommation d’API. Gemini le fera, bien que vous puissiez avoir besoin d’ajouter « Retournez un JSON valide et analysable » s’il commence à encapsuler le JSON dans des blocs de code markdown.

Cela seul réduit les erreurs d’analyse et les surprises comportementales spécifiques au modèle d’environ 60 % d’après mon expérience dans la construction des pipelines AlgoVesta.

Définition du Rôle et du Ton

La définition explicite du rôle fonctionne sur les trois modèles, mais la configuration diffère légèrement en termes de ton.

Claude répond bien au cadre collaboratif : « Vous êtes un expert en [domaine]. Aidez-moi à réfléchir à [problème]. » Il s’investit dans le rôle et a tendance à ajouter des nuances et des mises en garde sans qu’on le lui demande.

GPT-4o répond mieux au cadre directif : « Vous êtes un [rôle]. Votre tâche : [action spécifique]. » Il interprète cela comme une description de poste claire et exécute avec moins de pensées tangentielles.

Gemini se situe entre les deux – il répond aux deux styles, mais obtient de meilleurs résultats lorsque vous êtes explicite sur les contraintes : « Vous êtes un [rôle]. Répondez uniquement avec [type de sortie]. Ne faites pas [comportement à éviter]. »

Tous les trois bénéficient d’instructions de ton explicites :

## Trois modèles, structure similaire
Vous êtes un rédacteur de documentation technique pour des développeurs ayant une expérience intermédiaire en Python.

Ton : Direct et axé sur le code. Évitez le langage marketing. Supposez que le lecteur passera directement aux exemples de code.

Tâche : Expliquez [concept technique] d'une manière qui ait du sens pour quelqu'un qui comprend [prérequis] mais pas [ce nouveau concept].

Fournissez : explication (3-4 phrases maximum) + exemple de code fonctionnel + une erreur courante à éviter

La différence est subtile mais importante à grande échelle – le cadre directif pousse GPT-4o à être plus efficace. Le cadre collaboratif amène Claude à être plus réfléchi.

Techniques Spécifiques aux Modèles et Quand Elles Fonctionnent

Claude : Raisonnement Explicite et Chaîne de Pensée Étendue

L’entraînement Constitutional AI de Claude le rend exceptionnel pour montrer son raisonnement. Il effectue naturellement une chaîne de pensée sans qu’on le lui demande, et il gère mieux le « Je ne suis pas sûr » que les deux autres.

Exploitez cela avec des prompts qui invitent à la réflexion :

## Prompt optimisé pour Claude (raisonnement explicite)
Analysez ce ticket de support client pour le sentiment et l'urgence.

Avant de répondre, réfléchissez :
1. Quels mots ou phrases spécifiques indiquent l'état émotionnel ?
2. Y a-t-il une date limite explicite ou une pression temporelle ?
3. Qu'est-ce qui n'est PAS dit – qu'est-ce qui est implicite ?
4. Quel est mon niveau de confiance dans cette évaluation ?

Ensuite, retournez le JSON :
{
  "sentiment": "positif|neutre|négatif|mixte",
  "urgency_level": 1-5,
  "reasoning": "expliquez votre évaluation",
  "confidence": 0.0-1.0,
  "red_flags": ["liste des éléments préoccupants"]
}

Ticket :
[message client]

Claude excelle ici car vous lui demandez de ralentir et de réfléchir. Ce n’est pas vrai pour toutes les tâches – parfois la réflexion de Claude est excessive. Mais pour les jugements, la classification avec nuance et tout ce qui nécessite « expliquez votre raisonnement », ce schéma réduit mesurablement les taux d’erreur.

Quand NE PAS utiliser ceci : pour des tâches simples et factuelles (« extraire la date de cet e-mail »), le raisonnement étendu ajoute de la latence sans améliorer la précision. Claude devient plus rapide et plus précis si vous supprimez la demande de raisonnement.

GPT-4o : Exemples Few-Shot et Instructions Étape par Étape

GPT-4o a été entraîné pour suivre des instructions séquentielles complexes. Il répond exceptionnellement bien à l’apprentissage few-shot – lui montrer 2-3 exemples d’entrée et de sortie souhaitée – et à la décomposition des tâches en étapes numérotées.

## Prompt optimisé pour GPT-4o (few-shot + séquençage)
Extrayez des données structurées à partir des retours clients non structurés. Retournez du JSON.

Exemples :

Entrée : "L'application plante chaque fois que j'essaie de télécharger une photo. C'est ridicule."
Sortie : {"issue_type": "bug", "severity": "high", "affected_feature": "photo upload", "sentiment": "frustrated"}

Entrée : "Je viens de commencer à utiliser ça. Plutôt cool jusqu'à présent, bien qu'un peu cher."
Sortie : {"issue_type": "feedback", "severity": "low", "affected_feature": "pricing", "sentiment": "cautiously positive"}

Entrée : "Le mode sombre fonctionne très bien. Exactement ce dont j'avais besoin."
Sortie : {"issue_type": "praise", "severity": "low", "affected_feature": "dark mode", "sentiment": "positive"}

Maintenant, traitez ce retour :
1. Identifiez le problème ou le sujet principal
2. Attribuez un type : bug, demande de fonctionnalité, retour, ou éloge
3. Évaluez la gravité (1-5, où 5 = casse la fonctionnalité principale)
4. Extrayez la fonctionnalité à laquelle il se rapporte
5. Classez le sentiment
6. Retournez en JSON

Retour :
[message client]

Cela fonctionne car GPT-4o traite les exemples comme un signal d’apprentissage et les étapes numérotées comme un chemin d’exécution clair. Ajoutez 2-3 exemples et vous lui avez essentiellement montré le schéma. Il généralisera bien aux variations.

Mode d’échec : Si vous donnez à GPT-4o trop d’exemples contradictoires ou des instructions ambiguës, il tend vers le cas le plus courant dans vos exemples plutôt que de raisonner sur les cas limites. Claude signalerait l’ambiguïté. GPT-4o comble les lacunes.

Gemini 2.0 : Long Contexte et Spécification Agressive

Le véritable avantage de Gemini est sa fenêtre de contexte – jusqu’à 2 millions de tokens. Il est également fort sur les tâches multimodales (texte + image + vidéo + audio dans un seul prompt). Le compromis : il a parfois du mal avec le raisonnement abstrait sur de longs documents et bénéficie d’une sur-spécification.

## Prompt optimisé pour Gemini (contraintes explicites)
Vous analysez un document de spécifications techniques de 150 pages.

CONTRAINTE : Ne pas synthétiser ou inférer des informations qui ne sont pas explicitement indiquées. Si le document ne mentionne rien, dites "non spécifié" plutôt que de deviner.

CONTRAINTE : Citez les passages exacts lorsque vous soutenez des affirmations. Ne paraphrasez pas.

Tâche :
1. Extrayez toutes les exigences système (matériel, logiciel, dépendances)
2. Listez toutes les hypothèses que la spécification fait sur l'environnement de l'utilisateur
3. Identifiez toute contradiction entre les sections
4. Retournez en JSON

Format de retour :
{
  "requirements": [{"type": "string", "value": "string", "source_section": "string"}],
  "assumptions": [{"assumption": "string", "mentioned_in": "string"}],
  "contradictions": [{"claim_a": "string", "claim_b": "string", "sections": ["string", "string"]}]
}

Spécification :
[texte complet du document]

Gemini a besoin que vous soyez agressif dans la définition des limites. La raison : il est moins entraîné sur les réponses « Je ne sais pas » et plus entraîné sur la génération de texte plausible. Les contraintes explicites comme « ne pas inférer » et « citer exactement » le poussent vers la précision.

Là où Gemini brille : résumé de plusieurs documents, recoupement de sources dans des contextes très longs, extraction de schémas à partir de centaines de pages. Là où il lutte : raisonnement créatif ouvert, jugements sans critères clairs.

Créer un Prompt Qui Fonctionne sur les Trois

Une fois que vous comprenez les différences, vous pouvez écrire des prompts qui performent bien sur les trois modèles. La stratégie : optimiser pour le modèle le plus restrictif (l’entraînement à la sécurité de Claude), puis ajouter des améliorations spécifiques au modèle.

Voici un exemple de production d’AlgoVesta – un prompt qui classe les signaux de trading à partir de plusieurs sources de données :

## Prompt de base (fonctionne sur les trois)
Vous êtes un analyste financier évaluant des signaux de trading.

Analysez les signaux ci-dessous. Retournez du JSON avec la classification, la confiance et le raisonnement.

Contraintes :
- Utilisez uniquement les informations fournies dans les signaux. N'ajoutez pas de connaissances externes.
- Si les signaux se contredisent, identifiez la contradiction et indiquez votre intervalle de confiance.
- Évaluez votre certitude : 0.0 (pure supposition) à 1.0 (certain).

Signaux à analyser :
[données des signaux]

Retour :
{
  "primary_signal": "haussier|baissier|neutre",
  "confidence": 0.0-1.0,
  "contradictions": ["liste le cas échéant"],
  "reasoning": "pourquoi vous l'avez classé ainsi"
}

Ce prompt de base fonctionne sur les trois. Voici comment l’ajuster :

Pour Claude : Ajoutez « Réfléchissez à votre raisonnement étape par étape avant de répondre. » Claude sera naturellement plus approfondi. Reformulez les contraintes en questions : « Où les signaux se contredisent-ils ? Qu’est-ce qui manque ? »

Pour GPT-4o : Ajoutez 2-3 exemples de signaux avec leurs classifications attendues. Ajoutez des étapes numérotées : « 1. Extrayez les signaux haussiers. 2. Extrayez les signaux baissiers. 3. Comparez les niveaux de confiance. 4. Retournez le JSON. » GPT-4o suivra la séquence exactement.

Pour Gemini : Ajoutez des déclarations explicites « Ne faites pas » : « Ne référencez pas de connaissances externes du marché. Ne déduisez pas de contexte non fourni. » Ajoutez des spécifications de longueur de sortie : « Le raisonnement doit faire 1-2 phrases. » Rendez les contraintes à l’épreuve des balles.

Tests A/B des Prompts sur Différents Modèles

En production, vous devez savoir quel prompt fonctionne le mieux pour quel modèle. Cela nécessite des tests systématiques.

Étape 1 : Définissez votre métrique. « Mieux » signifie différentes choses pour différentes tâches. Pour la classification, c’est la précision. Pour la synthèse, c’est la couverture + la concision. Pour les tâches créatives, c’est la nouveauté + la pertinence.

Étape 2 : Créez des cas de test. Minimum 20 exemples. Ils doivent représenter les cas limites et les cas courants. Un jeu de données équilibré détecte les échecs de prompt que vous manqueriez avec seulement des exemples faciles.

Étape 3 : Exécutez toutes les variantes de prompt sur tous les cas de test avec tous les modèles. C’est fastidieux. Automatisez cela avec un simple script Python qui boucle sur les modèles et les variantes, puis enregistre les résultats dans une feuille de calcul.

## Exemple de système de test (Python)
import anthropic
import openai
from google import genai
import json
import csv

test_cases = [
    {"input": "exemple 1", "expected": "sortie attendue 1"},
    {"input": "exemple 2", "expected": "sortie attendue 2"},
    # ... 18 autres cas de test
]

prompt_variants = {
    "base": "votre prompt de base",
    "with_reasoning": "base + instruction de raisonnement",
    "few_shot": "base + 2-3 exemples",
}

models = {
    "claude": "claude-3-5-sonnet-20241022",
    "gpt4o": "gpt-4o-2024-11-20",
    "gemini": "gemini-2.0-flash",
}

results = []

for model_name, model_id in models.items():
    for variant_name, prompt_template in prompt_variants.items():
        for test_case in test_cases:
            # Appeler le modèle avec cette variante spécifique
            if model_name == "claude":
                client = anthropic.Anthropic()
                response = client.messages.create(
                    model=model_id,
                    max_tokens=1024,
                    messages=[{"role": "user", "content": prompt_template + "\n\n" + test_case["input"]}]
                )
                output = response.content[0].text
            # ... similaire pour GPT et Gemini
            
            # Évaluer la sortie (vous définissez cela)
            score = evaluate_output(output, test_case["expected"])
            results.append({
                "model": model_name,
                "variant": variant_name,
                "test_id": test_case.get("id"),
                "score": score
            })

# Écrire les résultats dans un fichier CSV
with open("results.csv", "w") as f:
    writer = csv.DictWriter(f, fieldnames=["model", "variant", "test_id", "score"])
    writer.writeheader()
    writer.writerows(results)

# Agréger par modèle + variante
agg = {}
for r in results:
    key = (r["model"], r["variant"])
    if key not in agg:
        agg[key] = []
    agg[key].append(r["score"])

for (model, variant), scores in agg.items():
    avg_score = sum(scores) / len(scores)
    print(f"{model} + {variant}: {avg_score:.2f}")

Cela prend 2-3 heures à configurer, mais permet d’économiser des semaines de devinettes. Une fois que vous avez les résultats, vous pouvez choisir la combinaison prompt-modèle optimale pour votre cas d’utilisation, ou utiliser une approche d’ensemble (router certaines requêtes vers Claude, d’autres vers GPT-4o en fonction des caractéristiques de l’entrée).

Échecs Courants et Comment les Éviter

Ces schémas échouent systématiquement sur les trois modèles s’ils ne sont pas gérés correctement :

Hallucinations sur les tâches factuelles : Les trois modèles inventeront des informations plausibles lorsqu’ils manqueront de données d’entraînement. Solution : interdire explicitement l’inférence. « Utilisez uniquement les informations fournies. Si ce n’est pas mentionné, dites ‘non fourni’ plutôt que de deviner. » Cela fonctionne partout.

Manipulation des instructions du prompt : Un modèle suivra la dernière instruction qui semble avoir la priorité la plus élevée. Si vous dites « soyez concis » et « expliquez en détail », il en choisit une. Solution : soyez explicite sur les compromis. « Privilégiez la précision à la brièveté. Une réponse plus longue mais correcte est meilleure qu’une réponse courte mais incomplète. »

Dérive du format : Le modèle commence à suivre parfaitement votre format, puis l’abandonne en cours de route. Solution : répétez l’instruction de format à la fin du prompt. « Retournez toutes les réponses au format JSON. N’ajoutez pas de formatage markdown. »

Surcharge de la fenêtre de contexte : Vous fournissez 100k tokens et le modèle a du mal avec le raisonnement. Le problème n’est pas la taille – c’est que des contextes très longs dégradent l’attention. Solution : résumez ou filtrez le contexte avant de l’envoyer. Pour Gemini spécifiquement, divisez les tâches multi-documents en morceaux plus petits même s’il peut gérer 2 millions de tokens.

Quand Router vers des Modèles Spécifiques

Vous n’avez pas besoin d’une ingénierie de prompt égale pour les trois. Parfois, un modèle est le vainqueur clair. Savoir quand vous fait gagner du temps et des tokens.

Votre Action Cette Semaine

Choisissez une tâche pour laquelle vous utilisez actuellement un LLM. Réécrivez votre prompt en utilisant le format de sortie structurée (JSON avec des clés explicites), ajoutez la définition du rôle et testez-le sur les trois modèles avec 10 exemples réels de vos données.

Enregistrez les résultats. Quel modèle obtient les meilleures performances ? Quelle variante de prompt a le mieux fonctionné ? Passez 90 minutes sur cela – pas plus. Vous aurez une décision basée sur des données quant à quel modèle utiliser et exactement comment le solliciter. C’est mieux que de deviner.