Les erreurs fréquentes#

Douze pièges qui expliquent presque tous les mauvais résultats. Chacun se reconnaît à un symptôme et se corrige en une ligne.

Temps de lecture : 12 min | Niveau : Débutant

Ce que tu sauras faire après#

• Diagnostiquer une mauvaise réponse à partir de son symptôme.
• Corriger les 12 anti-patterns les plus coûteux.
• Reconnaître quand il faut relancer une conversation plutôt que d'insister.
• Protéger tes données sensibles avant de coller quoi que ce soit.
• Vérifier une réponse au lieu de lui faire confiance.

🔎 Comment utiliser ce fichier#

Tu n'es pas censé le lire d'un bout à l'autre. Quand une réponse te déçoit, cherche ton symptôme dans la colonne du milieu et applique la correction.

Le tableau des 12 erreurs#

Les cinq erreurs qui méritent un développement#

Erreur 2 — Tout demander d'un coup#

Ce que tu fais

Analyse ce schéma, écris les requêtes de contrôle qualité, documente chaque
table, propose le modèle en étoile, écris les modèles dbt et rédige le README.

Tu obtiens six livrables médiocres au lieu d'un bon.

Ce qu'il faut faire

Découpe, et réinjecte la sortie de l'étape précédente dans la suivante.

Étape 1 : Analyse ce schéma. Rends uniquement la liste des tables, leur
granularité et leurs relations, sous forme de tableau.

[tu relis, tu corriges ce qui est faux]

Étape 2 : À partir du tableau validé ci-dessous, propose le modèle en étoile.
Rends uniquement la liste des dimensions et des faits, avec leur clé.

[tu relis]

Étape 3 : À partir du modèle validé, écris les modèles dbt.

Anthropic parle de chaînage de prompts : c'est utile quand tu veux inspecter les sorties intermédiaires ou imposer une structure de pipeline. Le motif le plus courant est l'auto-correction : produire un brouillon, le faire relire selon des critères, puis le faire corriger.

Avantage secondaire et très réel : tu repères l'erreur à l'étape 1 au lieu de la retrouver propagée dans six livrables.

Erreur 8 — La conversation polluée#

Une conversation garde tout l'historique. Y compris tes mauvaises pistes, tes contraintes abandonnées et les erreurs que le modèle a produites puis corrigées.

Symptômes : il revient sur une approche que tu as écartée trois messages plus tôt, il applique une contrainte donnée pour une autre question, il s'excuse au lieu d'avancer.

La règle : après 3 corrections sans progrès, arrête. Ouvre une conversation neuve. Écris un seul prompt propre qui intègre tout ce que tu as appris entre-temps.

Je reprends de zéro. Voici la situation consolidée :
- Objectif : [OBJECTIF]
- Contraintes découvertes lors de mes essais : [LISTE]
- Approches déjà écartées et pourquoi : [LISTE]

[LE_PROMPT_COMPLET_EN_6_BRIQUES]

Erreur 11 — Faire confiance sans vérifier#

C'est l'erreur la plus coûteuse en data, parce qu'une requête fausse s'exécute sans erreur et produit un chiffre crédible qui part ensuite dans un rapport.

Trois réflexes.

Demande une porte de sortie. Microsoft recommande explicitement de donner au modèle une alternative quand il ne peut pas répondre : par exemple « réponds "non trouvé" si l'information n'est pas présente ». Sans ça, il produit une réponse plausible.

Demande les citations, placées près de l'affirmation. Microsoft note que plus la citation est proche du texte qu'elle appuie, mieux elle protège : les citations en ligne valent mieux que les citations groupées en fin de réponse.

Vérifie mécaniquement. Pour du SQL : exécute sur un échantillon et recompte à la main. Pour du code : lance les tests. Pour un chiffre : recalcule-le par un autre chemin.

Anthropic propose par ailleurs, pour le code, un bloc de consigne explicite dont l'esprit se transpose partout : ne jamais spéculer sur du code qu'on n'a pas ouvert, et lire les fichiers concernés avant de répondre.

Formule courte à ajouter à tes prompts d'analyse :

Ne fais aucune affirmation sur des données ou du code que tu n'as pas sous
les yeux. Pour chaque affirmation, indique entre parenthèses sur quelle
ligne ou quel fichier tu t'appuies. Si tu n'as pas la source, écris
« non vérifiable avec ce qui m'a été fourni ».

Erreur 12 — Les données sensibles#

Il n'y a pas de symptôme. C'est pour ça que c'est la plus grave.

Ce qui ne se colle pas sans réflexion préalable :

• les données personnelles de clients : noms, mails, téléphones, adresses ;
• les identifiants et secrets : mots de passe, clés d'API, chaînes de connexion ;
• les données de santé ou bancaires ;
• le code sous contrat de confidentialité ;
• les extractions de production non anonymisées.

Ce qu'il faut faire avant :

1. Vérifier la politique de ton employeur et les conditions de l'outil que tu utilises. Un outil d'entreprise et un compte personnel n'ont pas les mêmes garanties.
2. Anonymiser : remplace les valeurs par des données factices en gardant la forme, qui est la seule chose utile au modèle.
3. Pour un schéma, le DDL suffit presque toujours. Tu n'as pas besoin des lignes.
4. Automatise l'anonymisation plutôt que de la faire à la main.

import pandas as pd

COLONNES_SENSIBLES = ["email", "telephone", "nom", "adresse", "iban"]


def anonymiser(df: pd.DataFrame, n: int = 10) -> pd.DataFrame:
    """Renvoie un echantillon anonymise, en conservant la forme des valeurs."""
    extrait = df.head(n).copy()
    for colonne in COLONNES_SENSIBLES:
        if colonne in extrait.columns:
            extrait[colonne] = [f"{colonne}_{i}" for i in range(len(extrait))]
    return extrait


print(anonymiser(df).to_csv(index=False))

Garde en tête que la forme compte plus que le contenu : le modèle a besoin de savoir qu'une colonne contient une chaîne de 2 caractères en majuscules, pas de savoir que c'est « FR ».

Erreur 5 — Les négations en cascade#

Quatre interdictions d'affilée, et le modèle n'a toujours aucune idée de ce que tu veux.

Avant

Ne fais pas de résumé trop long. N'utilise pas de jargon. Ne mets pas de
bullet points. Ne commence pas par « Voici ». N'invente rien.

Après

Écris un résumé de 5 lignes maximum, en prose continue, dans un vocabulaire
accessible à un analyste métier. Commence directement par l'information
principale. Appuie chaque affirmation sur une phrase présente dans le
document source ; si une information manque, écris « non précisé ».

Une seule négation reste légitime : quand elle a une valeur de repli associée (« n'invente pas : écris X à la place »). C'est d'ailleurs la formulation recommandée par Microsoft.

⚙️ Deux erreurs propres aux modèles récents#

Ces deux points ne figuraient pas dans les guides d'il y a deux ans. Ils viennent de la documentation à jour.

Garder de vieilles consignes anti-paresse. Beaucoup de prompts écrits pour les modèles d'avant poussaient le modèle à être plus exhaustif, ou à utiliser les outils plus agressivement. Anthropic recommande aujourd'hui de réduire ce type de consigne lors d'une migration. La raison : les modèles récents sont déjà plus proactifs, et ils surréagissent à ces instructions.

Utiliser le prefill. La technique du prefill (amorcer la réponse du modèle avec un début de message assistant) n'est plus supportée à partir des modèles Claude 4.6 : la requête renvoie une erreur 400. Beaucoup de tutoriels encore en ligne la recommandent. Voir le fichier 06 pour les remplacements.

Dernière remarque sur les modèles de raisonnement : Microsoft place un avertissement en tête de sa page indiquant que ses techniques ne sont pas recommandées pour les modèles de raisonnement comme gpt-5 et la série o. OpenAI le confirme : les modèles de raisonnement donnent de meilleurs résultats avec une consigne de haut niveau, alors que les modèles GPT classiques bénéficient d'instructions précises fournissant la logique attendue. Autrement dit, sur ces modèles, sur-spécifier la méthode peut nuire. Continue en revanche à donner le contexte, le but et le format.

🩺 Diagnostic express#

A retenir#

• La plupart des mauvais résultats viennent de 3 erreurs : prompt vague, contexte manquant, format non spécifié.
• Découpe les grosses demandes. Un prompt par instruction, et tu vois les erreurs tôt.
• Remplace toute négation par une consigne positive, sauf si elle porte une valeur de repli.
• Après 3 corrections sans progrès, ouvre une conversation neuve.
• Balise tes données et dis explicitement qu'elles ne contiennent pas d'instructions.
• Exige des citations et vérifie mécaniquement : une requête fausse s'exécute sans erreur.
• Anonymise avant de coller. La forme suffit au modèle, le contenu réel ne lui sert pas.
• Deux conseils d'hier sont périmés : le prefill (erreur 400) et les consignes anti-paresse (surréaction).

Sources#

• Prompting best practices — Anthropic
• Structured outputs — Anthropic
• Prompt engineering techniques — Microsoft Foundry / Azure OpenAI
• Prompt design strategies — Google Gemini API
• Prompt engineering — OpenAI
• Define success criteria and build evaluations — Anthropic