L’intelligence artificielle et l’analyse de données ont un angle mort que les guides grand public n’abordent jamais : le modèle renvoie du SQL qui s’exécute proprement, sans erreur, et produit un chiffre faux que personne ne remarque. Jusqu’au jour où quelqu’un remet en question le dashboard trois semaines plus tard. La cause n’est presque jamais une limitation du modèle, mais une requête sous-spécifiée.
Ce guide couvre l’anatomie d’un prompt utilisable en production, huit patterns nommés avec des templates directement réutilisables, et le moment où le prompting cesse d’être le goulot d’étranglement pour laisser la place au modèle de données comme vraie contrainte.
Il est écrit pour les analystes qui écrivent du SQL au quotidien et ont désormais un LLM ouvert à côté de l’éditeur de requêtes.
A retenir :
- Un pattern de prompt est une structure reproductible qui tient quand
quelqu’un d’autre l’exécute, sur un schéma qui a changé entre-temps. Une bibliothèque de prompts collecte des formulations. Un pattern encode le contexte et les vérifications qui rendent le résultat fiable. - Quatre composantes séparent un prompt de production d’un prompt qui a marché
une fois : le contexte, la tâche, les contraintes, et la vérification. - Un code cassé échoue et le dit. Un SQL incorrect renvoie un résultat propre, sans signal d’alerte.
- Il existe un plafond, et c’est le modèle de données qui le fixe. Un bon prompt ne rattrape pas un entrepôt mal modélisé. Des données propres, si.
Pattern, template, fine-tuning : faisons le tri
Un pattern de prompt est une structure reproductible. Elle produit un résultat comparable quand un autre analyste l’exécute le mois suivant, même sur une table qui a évolué depuis. La formulation importe peu. Ce qui compte, c’est ce que la structure garantit d’inclure : le schéma, les règles métier, la forme attendue de la réponse, et un moyen de la vérifier.
C’est cette garantie qui distingue un pattern des deux choses auxquelles on le confond le plus souvent : les bibliothèques de prompts et le fine-tuning.
- Une bibliothèque de prompts collecte des formulations qui ont fonctionné une fois. Elle devient obsolète dès que le schéma ou la version du modèle change en dessous.
- Le fine-tuning modifie le modèle plutôt que la requête. C’est pertinent à grande échelle, mais à côté du vrai problème : le modèle n’a simplement jamais su ce que signifie « client actif » dans votre entreprise.
Un prompt qui fonctionne vs. un prompt qui continue de fonctionner
Voici le test. Prenez le prompt qui a produit votre meilleur résultat la semaine dernière, collez-le dans une nouvelle session sans historique, et passez-le à un collègue qui n’a pas vu la conversation. Si le résultat se dégrade, le prompt n’a jamais été ce qui avait de la valeur, c’était la conversation et vous l’avez perdue en fermant l’onglet.
La plupart de ce qui circule en interne comme « un super prompt » échoue exactement de cette façon. Son auteur avait passé vingt minutes en amont à décrire les tables, corriger les trois premières tentatives du modèle, et préciser que les remboursements apparaissent comme des lignes négatives dans la table de détail plutôt que dans une table dédiée. Rien de tout cela n’apparaît dans le message final, qui est la seule partie que tout le monde copie.
Pourquoi le SQL généré par IA échoue en silence
Dans une application, les erreurs s’annoncent. En SQL analytique, elles se cachent. Les tests échouent, le build casse, une exception remonte dans les logs. Une requête, elle, renvoie des lignes. Ces lignes alimentent un graphique, le graphique arrive en réunion, et la seule couche de validation repose sur le fait que quelqu’un dans la salle sache à peu près à quoi le chiffre devrait ressembler.
Les échecs où le modèle produit du nonsense vous coûtent trente secondes. Les échecs coûteux, eux, paraissent parfaitement raisonnables. Quand l’écart est de 8 % plutôt que de 80 %, personne ne le voit. Cette asymétrie fait du prompt engineering pour la business intelligence une discipline différente du prompt engineering pour le développement logiciel. C’est aussi pour ça que les patterns ci-dessous s’appuient autant sur la vérification.
L’écart de confiance est mesurable
Le Stack Overflow Developer Survey 2025, qui s’appuie sur plus de 49 000 réponses, révèle que 84 % des développeurs utilisent ou prévoient d’utiliser des outils IA, mais que seulement 33 % font confiance à la fiabilité des résultats produits, contre 46 % qui s’en méfient activement. Seuls 3 % déclarent un niveau de confiance élevé, et les répondants les plus expérimentés sont les plus sceptiques.
Deux autres chiffres éclairent pourquoi. Environ deux tiers citent des solutions IA qui s’approchent du bon résultat sans l’atteindre, et 45 % signalent que déboguer du code généré par IA leur prend plus de temps. Ce sont des développeurs, pas des analystes, ce qui mérite d’être gardé en tête, même si le constat s’applique directement à quiconque écrit des prompts LLM pour du SQL. « Presque juste » est le pire résultat possible, parce que c’est « presque juste » qui passe en production.
Les erreurs silencieuses atteignent la production
Une condition de jointure incorrecte renvoie quand même un résultat. Un DISTINCT manquant aussi. Un filtre appliqué après l’agrégation quand il aurait dû l’être avant, également.
Un analyste demande le chiffre d’affaires mensuel par canal. Le modèle récupère les montants dans la table de détail, puis fait une jointure gauche vers les attributions de campagne pour obtenir le canal. Une même commande peut porter deux ou trois attributions. Chaque ligne de détail est dupliquée autant de fois qu’il y a d’attributions avant que le SUM ne s’exécute, et le chiffre d’affaires ressort avec 8 % de trop. Le graphique s’affiche, le chiffre est plausible, et il reste dans le deck mensuel pendant six semaines, jusqu’à ce que la finance réconcilie avec le grand livre et pose une question à laquelle personne ne peut répondre immédiatement.
Trois modes d’échec à connaître
Les erreurs de logique silencieuses correspondent à la catégorie précédente : du SQL valide, un grain incorrect, un résultat qui a l’air juste.
La dérive de définition survient quand le modèle fournit sa propre interprétation d’une métrique métier faute d’en avoir reçu une. Demandez le taux de churn dans trois sessions distinctes : vous obtiendrez trois formules défendables, aucune ne correspondant à ce qui figure dans votre deck board.
L’effondrement de contexte prend les équipes par surprise. Tout ce dont le modèle avait besoin avait été établi au fil des échanges précédents, dans une conversation qui n’existe plus. Le prompt partagé reproduit la formulation, pas le contexte. Il fonctionne pour son auteur, qui comble mentalement les lacunes sans s’en rendre compte, et échoue pour tout le monde autour de lui.
Ce que contient un prompt utilisable en production
Quatre composantes. Tous les patterns de la bibliothèque ci-dessous en appliquent une ou plusieurs.
Contexte
La structure de chaque table concernée : noms des colonnes, types de données et clés, la signification de toute colonne dont le nom ne s’explique pas de lui-même, et les règles métier qui gouvernent les données. Les codes de statut, les flags de suppression logique, un exercice fiscal qui commence en avril, les comptes de test à exclure. Tout ce qu’un collègue dirait à un nouvel
arrivant doit figurer ici, parce que le modèle est en permanence dans sa première semaine.
Tâche
Le grain, le champ de date sur lequel filtrer, le traitement des cas limites, et la question exacte. Presque tous les mauvais résultats remontent à une question qui admet plusieurs réponses correctes. « Chiffre d’affaires par mois » ne précise pas si on utilise la date de commande ou la date d’expédition, si les remboursements sont déduits, ni si une ligne représente un mois ou un mois par canal.
Contraintes
Le dialecte, le format de sortie, les conventions de nommage, et ce qu’il ne faut pas retourner. C’est la composante que les analystes omettent le plus souvent, parce qu’elle donne l’impression de soigner la forme plutôt que le fond. Une requête accompagnée de trois paragraphes d’explication inutiles, en camelCase sur un entrepôt en snake_case, dans un dialecte qui ne supporte pas votre fonction fenêtre : ça coûte du temps à corriger à chaque exécution.
Vérification
Quelque chose qui permet de contrôler la réponse sans la recalculer à la main : des nombres de lignes attendus, des hypothèses explicitement posées, ou une seconde requête sur un chemin de jointure différent qui devrait retourner le même chiffre. Cela transforme une réponse plausible en une réponse vérifiable, et c’est ce qui distingue ceux qui font confiance à leurs résultats assistés par IA de ceux qui ont discrètement arrêté de l’utiliser.
Huit patterns de prompts utilisables en production
Chaque pattern nomme l’échec qu’il prévient et fournit un template à adapter. Ce sont des templates de prompts pour analystes, pas des conseils de formulation : ils sont volontairement verbeux. Compressez-les une fois que vous savez quelles parties vous sont utiles.
Les prompts ci-dessous sont traduits en français. Si vous préférez travailler avec des prompts en anglais, vous pourrez les trouver sur la version anglaise de l’article.
Le schéma avant la question
Commencez par les tables et les règles, puis posez la tâche. L’ordre compte plus qu’on ne le pense : un modèle qui lit la question en premier commence à faire du pattern-matching sur des schémas génériques avant même d’avoir vu le vôtre.
Voici les tables concernées :
<structure de chaque table, avec les types et les clés>
Règles métier applicables :
-orders.status = 'C' signifie complété, pas annulé
-les remboursements sont enregistrés comme des lignes négatives dans order_lines, pas dans une table séparée
-l'exercice fiscal commence le 1er avril
-accounts.is_internal = true identifie les comptes de test, à exclure systématiquement
Ne requête aucune table absente de cette liste. Si tu en as besoin d'une qui n'y figure pas, dis-le plutôt que d'en deviner le nom.Cette dernière instruction fait un travail surprenant. Sans elle, un modèle qui a besoin d’une table customers l’écrira dans la clause FROM et continuera.
Définir le format attendu
Ce qui est renvoyé doit être suffisamment prévisible pour être collé directement, sans retouche.
Renvoie :
1.Une seule requête SQL, dialecte PostgreSQL 15, dans un seul bloc de code
2.Rien d'autre. Pas d'explication, pas d'alternatives, pas de commentaire.
Formatage : les CTEs en snake_case, une colonne par ligne dans le SELECT final, les mots-clés en majuscules, jamais de SELECT *.
Si tu ne peux pas produire la requête avec les informations fournies, renvoie le mot BLOCKED et une ligne indiquant ce qui manque.La trappe de sortie BLOCKED vaut la peine d’être adoptée. Sans alternative, un modèle produira toujours quelque chose, et quelque chose est pire que rien quand vous comptiez sur le silence pour signaler un problème.
Vos propres requêtes comme exemples
Deux ou trois requêtes de votre équipe, collées en entier, enseignent des conventions qu’aucune description ne transmettra.
Voici deux requêtes issues de notre dépôt. Respecte leur structure, leur nommage et leur style de commentaires.
[Exemple 1]
<coller une vraie requête, sans modification>
[Exemple 2]
<coller une deuxième vraie requête>
Écris maintenant une requête qui : <tâche>Choisissez des exemples représentatifs plutôt qu’impressionnants. Une requête ingénieuse apprend au modèle à être ingénieux, ce qui est rarement ce qu’on attend d’un SQL que quelqu’un d’autre devra maintenir.
Injection de métrique
Si la question nomme une métrique métier, la définition va dans le prompt. Pas une description, la définition exacte, dans la forme sur laquelle votre équipe s’est accordée.
Définition du chiffre d'affaires net, telle que maintenue par l'équipe finance :
Chiffre d'affaires net = gross_amount - discount_amount - refund_amount
Exclut : accounts.is_internal = true
Exclut : order_status = 'X'
Devise : convertie en EUR au taux du jour de la commande,
issu de fx_rates.daily_rate
Utilise cette définition telle quelle. Ne la remplace pas par la tienne.Ce pattern pointe vers un problème structurel plutôt que de prompting. Si vous collez la définition du chiffre d’affaires dans une fenêtre de chat, c’est que cette définition n’est centralisée nulle part, et la dérive qui apparaît dans les résultats de l’IA est déjà présente dans vos dashboards. Notre guide sur le SQL modulaire pour des KPIs cohérents (EN) couvre la correction de fond.
Construire et valider couche par couche
Les requêtes longues échouent au milieu. Construisez-les couche par couche et validez chacune avant d’ajouter la suivante.
Nous construisons cette requête couche par couche.
Écris uniquement le premier CTE : <décrire la couche 1>. Renvoie le CTE ainsi qu'un simple SELECT qui me permet d'inspecter son résultat. Arrête-toi là.
Je vérifierai le nombre de lignes avant de continuer.Tout ce qui dépasse deux CTEs (Common Table Expressions) mérite cette approche. Une erreur de logique détectée immédiatement coûte une minute ; la même erreur découverte sous quatre couches supplémentaires coûte un après-midi. Notre article sur la structuration des requêtes SQL pour les analystes BI développe ce point.
L’interprétation avant la requête
Forcez l’interprétation à la surface avant qu’aucun SQL n’apparaisse. La moitié du temps, vous détecterez le malentendu dès la première phrase de la réponse.
Avant d'écrire le moindre SQL, réponds à ces questions :
1.Quel sera le grain de chaque ligne de ton résultat ?
2.Sur quel champ date filtres-tu, et pourquoi celui-là ?
3.Quelle hypothèse fais-tu sur <l'élément ambigu> ?
4.Quelles lignes tes jointures vont-elles supprimer ou dupliquer ?
Attends ma confirmation avant d'écrire la requête.Utilisez ce pattern quand la question est nouvelle ou réellement ambiguë. Sur une extraction de routine, c’est du surcoût.
Auto-vérification
Demandez la vérification en même temps que la réponse, dans le même tour, pour que le contrôle ne coûte rien de plus.
En plus de la requête, renvoie :
-Le nombre de lignes attendu, avec ton raisonnement
-Une deuxième requête indépendante qui confirmerait ou contredirait la première, en utilisant un chemin de jointure différent ou une vérification par agrégat
-Toutes les hypothèses que tu as faites, sous forme de liste à pucesC’est le contrôle croisé indépendant qui fait la valeur du pattern. Deux requêtes sur des chemins différents qui arrivent au même résultat, c’est un signal fiable. Une requête qui a l’air juste, non.
Corriger plutôt que générer
Pointez le modèle sur une requête existante et demandez-lui ce qui ne va pas. La révision reçoit bien moins d’attention que la génération, et c’est pourtant le pattern vers lequel on se tourne le plus sur du code hérité.
Voici une requête existante et le schéma sur lequel elle s'exécute.
<requête>
<structure de chaque table, avec les types et les clés>
Identifie : le grain de jointure incorrect, les filtres appliqués après agrégation qui devraient l'être avant, la gestion des NULL qui modifie le résultat, et tout endroit où le SQL ne correspond pas à l'intention déclarée :
<intention>
Pour chaque problème : cite la ligne, explique son effet sur le résultat, et montre la correction.Une précision s’impose : un bilan favorable du modèle ne signifie pas que la requête est correcte. Traitez les résultats comme des pistes à investiguer, pas comme un certificat de conformité. Un dashboard retouché par quatre personnes sur deux ans reste un meilleur usage d’une heure que de générer quelque chose de nouveau, même si cette heure se termine avec vous en train de lire le SQL.
Quel pattern utiliser
| Pattern | Échec prévenu | À utiliser quand |
|---|---|---|
| Le schéma avant la question | Effondrement de contexte | Le modèle n’a pas vu ces tables dans cette session |
| Définir le format attendu | Résultat incohérent ou inutilisable | Le résultat va directement dans un dashboard ou un dépôt |
| Vos propres requêtes comme exemples | Dérive de conventions | Plusieurs personnes maintiennent la requête |
| Injection de métrique | Dérive de définition | La question nomme une métrique métier |
| Construire et valider couche par couche | Erreurs de logique silencieuses | La requête nécessite plus de deux CTEs |
| L’interprétation avant la requête | Mauvaise lecture des besoins | La question est ambiguë ou nouvellement cadrée |
| Auto-vérification | Erreurs silencieuses en production | Personne en aval ne recalculera le chiffre |
| Corriger plutôt que générer | Erreurs non détectées dans du SQL existant | Débogage ou audit de SQL existant |
Considérez ce tableau comme un point de départ ; en pratique, vous en combinerez trois ou quatre dans un seul prompt.
Ce que vos prompts ne peuvent pas corriger
Tout ce qui précède améliore votre taux de réussite. Rien n’en supprime le plafond.
Le benchmark BIRD est la mesure publique la plus réaliste de l’état actuel du prompt engineering text-to-SQL. Il s’appuie sur 12 751 paires question/requête testées sur 95 bases de données réelles couvrant plus de 37 domaines professionnels, loin des schémas épurés utilisés par les benchmarks précédents. La baseline humaine se situe à 92,96 % de précision d’exécution.
En août 2026, les meilleures soumissions se situent dans les basses quatre-vingts, avec le meilleur résultat sur modèle unique autour de 80 %. Les positions au classement évoluent en permanence : considérez ces chiffres comme un instantané. Une analyse CIDR 2026 sur les erreurs d’annotation dans les benchmarks text-to-SQL a également montré que la correction d’annotations erronées sur un échantillon du jeu de développement de BIRD faisait varier les scores individuels jusqu’à dix-neuf points. La précision d’exécution stricte pénalise donc certaines réponses qu’un évaluateur humain accepterait.
La direction est claire malgré tout. Sur des bases de données réalistes, avec le contexte métier fourni, les meilleurs systèmes disponibles restent significativement en deçà d’un humain expérimenté. Trois limites se situent entièrement hors de portée du prompt.
- Des données de mauvaise qualité. Vos tables ont des types incohérents, des codes de statut non documentés, trois définitions concurrentes d’un client. Les jointures ne fonctionnent que si vous savez lesquelles des quatre clés sont réelles. Le modèle hérite de tout ça, sans pouvoir distinguer ce qui est normal de ce qui est un problème. La structure dans le prompt ne compense pas l’absence de structure dans l’entrepôt. Soigner les fondations de données fait davantage pour l’analyse assistée par IA que n’importe quel template.
- Un contexte métier manquant. Le modèle ne sait pas que la campagne a été mise en pause deux semaines en juillet, qu’une migration a dupliqué des lignes de la table des commandes ou qu’une baisse sur une région reflète un jour férié plutôt qu’un effondrement de la demande. Ce qui revient est un SQL techniquement correct sur des données qui signifient autre chose que ce que les chiffres semblent dire, expliqué avec assurance.
- La responsabilité. Quelqu’un valide le chiffre qui arrive dans le deck du board. Cette obligation ne se transfère pas à un outil, et celui qui a exécuté le prompt est aussi pleinement responsable du résultat que s’il l’avait écrit lui-même.
Transformer un prompt qui fonctionne en pattern d’équipe
Le travail individuel atteint rapidement ses limites dans la création et l’utilisation des prompts SQL. Les équipes qui en tirent une valeur durable traitent les prompts comme n’importe quelle autre logique partagée.
- Capturez le prompt en entier, schéma et règles métier inclus. Le contexte est l’actif. La formulation est l’emballage, et la plupart des gens ne sauvegardent que l’emballage.
- Transformez les parties variables en template. Remplacez les éléments spécifiques par des placeholders nommés : noms de tables, plages de dates, définitions de métriques, grain. Ce qui reste est un template de prompt SQL réutilisable, et les placeholders documentent ce qu’un collègue doit fournir avant de l’utiliser.
- Constituez un petit jeu d’évaluation : cinq à dix questions dont vous connaissez déjà les réponses, à exécuter avant de standardiser le template. Cela prend un après-midi, et peu d’équipes le font, ce qui explique pourquoi si peu peuvent dire si leur prompt partagé fait mieux que ce qu’il remplace.
- Stockez-le là où vit le SQL : dans le dépôt, versionné, relu comme du code, à côté des requêtes qu’il génère. Un prompt qui dort dans une page que personne n’a ouverte depuis mars n’est pas un actif d’équipe. La même rigueur qu’un pipeline de données fiable s’applique ici.
- Désignez un responsable et définissez ce qui doit déclencher une révision. Les patterns se dégradent. Une version de modèle change, un schéma évolue, la finance révise une définition : autant de raisons pour lesquelles un template fiable depuis huit mois peut commencer à produire des résultats subtilement différents. Pensez à noter les critères de revalidation.
Les tests de régression de prompts pour les équipes analytics sont un territoire presque vierge. Faites-le bien et vous aurez une longueur d’avance sur la majorité du terrain.
Comment ClicData soutient l’analyse assistée par IA sur des données gouvernées
Relisez les huit patterns : un thème se dégage. L’ancrage par le schéma existe parce que le modèle ne connaît pas vos tables. L’injection de métrique existe parce que la métrique n’a jamais été définie de façon centralisée. La plupart de la bibliothèque compense un contexte qu’une plateforme devrait fournir. Chaque point ci-dessous est donc associé au pattern qu’il rend superflu.
Consolidation des sources, contre l’ancrage par le schéma. Avec plus de 500 connecteurs alimentant un seul entrepôt, les tables derrière une métrique se trouvent au même endroit, sous un même ensemble de noms. La raison la plus courante d’ajouter des paragraphes d’explication de schéma avant de pouvoir poser une question disparaît.
Transformation et validation des données, sans erreurs de logique silencieuses. Le module Data Flow gère le nettoyage, la correction des types, la déduplication, les jointures et les lookups sur plus de 35 nœuds de traitement. Les données qu’une fonctionnalité IA lit ont déjà reçu le traitement que vous auriez sinon décrit dans un prompt en espérant que le modèle l’applique.
Des calculs définis une fois et réutilisés, contre l’injection de métrique. Un Data Flow écrit son résultat dans une table que n’importe quel dashboard peut lire. Une métrique calculée dans un flow alimente tous les rapports construits dessus, plutôt que d’être réimplémentée à chaque requête. La couche sémantique de ClicData, attendue pour le T4 2026, va plus loin en stockant la définition canonique elle-même, ce qui supprime complètement l’étape de copier-coller.
Le générateur de formules IA, contre la composante Contexte. Dans le Data Flow, l’assistant IA lit le contexte de votre pipeline, noms de colonnes et types de données inclus, lorsque vous décrivez un calcul en langage naturel. L’ancrage est géré par l’outil, pas par vous.
Les requêtes en langage naturel dans le module Insights, contre l’ensemble de la bibliothèque. Posez la question, ClicData génère la requête de son côté, l’exécute sur votre base de données, et maintient le contexte sur les questions suivantes quand vous ajoutez un filtre ou changez la plage de dates. La structure de la requête est transmise à OpenAI, vos données ne le sont pas, ce qui a son importance quand l’alternative consiste à coller des lignes de production dans une fenêtre de chat.
Ask AI, contre le self-service non gouverné. Le widget Ask AI est strictement limité aux datasets que vous lui assignez, et les permissions suivent les mêmes règles d’accès que le reste de la plateforme. La question d’un utilisateur métier ne se résout que sur les données auxquelles il avait déjà accès.
Les analyses narratives et les agents IA, contre le prompting lui-même. Les résumés au niveau des graphiques sont générés automatiquement, avec un ton et un niveau de détail configurés via le pré-prompting. Les agents IA sont conçus pour surveiller les données en continu et alerter quand des conditions sont remplies, couvrant les insights que personne ne devrait avoir à demander. Nous avons écrit séparément sur la place des agents dans un workflow de données.
En toute transparence : le modèle Data Flow demande un temps d’apprentissage réel, notamment pour les analystes qui viennent d’un environnement purement SQL. La communauté ClicData est plus petite que celles des grands acteurs établis, donc il y a moins de réponses disponibles quand on est bloqué. Ce qui comble cet écart, ce sont des personnes plutôt que des fils de forum : le programme d’onboarding vous met en contact avec des analystes internes pour la formation et l’implémentation, et des spécialistes produit répondent depuis le chat intégré pendant que vous construisez. Les fonctionnalités IA sont également disponibles sur les plans payants, certaines nécessitant un niveau supérieur.
Démarrez un essai gratuit de 15 jours ou réservez une session de démo personnalisée avec l’équipe pour voir comment cela fonctionne sur vos propres données.
Conclusion : traitez le prompt comme une spécification
Les patterns qui tiennent sont structurels, pas ingénieux : contexte, tâche, contraintes, vérification, appliqués de façon cohérente et stockés là où vit le reste de votre logique. Les analystes qui obtiennent des résultats fiables avec l’IA ne sont pas ceux qui formulent mieux leurs questions. Ce sont ceux qui ont arrêté de traiter le prompt comme une question et ont commencé à le traiter comme une spécification.
Le modèle de données fixe le plafond de tout le reste, et c’est là que se trouve le vrai travail pour la plupart des équipes.
Prenez la requête que votre équipe réexécute le plus souvent, réécrivez-la comme un template avec un format de sortie attendu et une requête de validation, testez-la sur cinq questions dont vous connaissez les réponses, et observez ce que ça fait au taux de réussite.
FAQ
En quoi un template de prompt est-il différent d’un prompt qui a simplement fonctionné une fois ?
La différence apparaît au moment de le partager. Un pattern porte son propre contexte, ce qui lui permet de fonctionner dans une nouvelle session lancée par quelqu’un d’autre. Un prompt ad hoc, lui, dépendait souvent de vingt minutes de conversation qui n’ont jamais été copiées avec la formulation.
Pourquoi l’IA génère-t-elle du SQL qui semble correct mais renvoie de mauvais chiffres ?
Parce que SQL valide et SQL correct sont deux choses différentes. Un grain de jointure cassé, un DISTINCT manquant ou un filtre appliqué après agrégation renvoient tous des résultats bien formés, sans que rien dans le chemin d’exécution ne signale l’erreur. Cela ne se voit que lorsque quelqu’un réconcilie le chiffre avec une autre source.
Les analystes devraient-ils inclure des exemples de requêtes dans leurs prompts ?
Oui, avec leurs propres requêtes plutôt que des exemples génériques. Deux ou trois vraies requêtes de votre dépôt transmettent les conventions de nommage, la structure des CTEs et les habitudes de commentaire bien plus efficacement qu’une description en prose.
Comment empêcher un LLM d’inventer ses propres définitions de KPI ?
Collez la définition canonique dans le prompt et demandez explicitement au modèle de ne pas la remplacer par la sienne. Si vous vous retrouvez à faire cela souvent, le problème de fond est que la définition n’est centralisée nulle part.
Les patterns de prompts se transfèrent-ils d’un modèle IA à un autre ?
Les structures se transfèrent bien : contexte, contraintes et vérification sont utiles quel que soit le modèle qui les lit. Les spécificités voyagent moins bien. Un template optimisé pour un modèle mérite d’être repassé sur votre modèle d’évaluation après un changement.
Comment une équipe BI devrait-elle stocker et partager ses prompts ?
Dans le dépôt, aux côtés du SQL, versionné et relu comme du code, avec les parties variables transformées en placeholders nommés. Chaque pattern doit avoir un responsable et une condition documentée qui déclenche sa revalidation ou son retrait.
Le prompt engineering remplace-t-il les compétences SQL pour les analystes ?
Non, et il élève le niveau plutôt qu’il ne l’abaisse. Vérifier si le SQL généré est correct demande plus de maîtrise que l’écrire soi-même : il faut lire une logique inconnue sous contrainte de temps, en cherchant des erreurs qui ne s’annoncent pas d’elles-mêmes.
Comment écrire un prompt qui génère du SQL correct pour des projets analytics ?
Fournissez quatre éléments : la structure de chaque table concernée et ses règles métier, un énoncé de tâche précisant le grain, le champ de date et la gestion des cas limites, des contraintes couvrant le dialecte et le format de sortie attendu, et une demande de vérification comme un nombre de lignes attendu ou une requête de contrôle croisé indépendante.