Ingénierie de prompt avancée
Techniques avancées pour structurer un prompt et utiliser l'IA comme partenaire de réflexion : diagnostic, comparaison, décision, critique et priorisation.
Cette page reprend en texte une série de conseils qui existaient sous forme de captures. Le but est de rendre ces idées consultables, indexables et réutilisables dans la rubrique IA, sans dépendre d'une image pour comprendre la méthode.
On reste ici sur des principes pratiques : cadrer les interdits, structurer les étapes, imposer un format, séparer les couches d'instructions, enchaîner les prompts et demander une vérification finale.
Les contraintes négatives évitent beaucoup de dérives. Au lieu de demander seulement un ton "professionnel", précisez ce qu'il faut éviter : pas de jargon, pas d'hypothèse non justifiée, pas de phrase trop longue, pas de changement d'API, pas d'action hors périmètre.
Exemple : - N'utilise pas de jargon. - Ne suppose aucune connaissance technique préalable. - Ne change pas l'API publique. - Ne propose pas de dépendance supplémentaire.
Pour les sujets un peu complexes, demandez une démarche ou une séquence d'analyse avant la sortie finale. Dans la pratique, cela revient à demander un plan, des hypothèses et des vérifications, puis seulement la réponse exploitable.
Exemple : Avant de conclure, donne : 1) ton analyse courte ; 2) les points à vérifier ; 3) la réponse finale.
Si le format compte vraiment, ne demandez pas seulement "sois structure". Donnez une forme explicite, stable et vérifiable. Cela peut être un plan, un tableau, une checklist ou un balisage simple de type XML.
Exemple : <answer> <main_point>...</main_point> <evidence>...</evidence> <conclusion>...</conclusion> </answer>
Quand vous montrez un exemple, ne montrez pas seulement entrée puis sortie. Si possible, montrez aussi le type de raisonnement ou de justification attendu entre les deux. Cela aide à mieux reproduire la méthode, pas seulement le résultat brut.
Exemple : INPUT : [la tâche] RAISONNEMENT ATTENDU : [pourquoi cette approche convient] OUTPUT : [résultat final]
Il faut séparer le cadre global et la demande ponctuelle. Une couche donne les règles stables, l'autre porte la tâche du moment. C'est exactement l'idée d'un fichier d'instructions de projet d'un côté et d'un prompt concret de l'autre.
Structure recommandee : SYSTEME : rôle, règles, interdits, style, validations. UTILISATEUR : contexte réel, fichiers, question, objectif, format attendu.
Quand l'outil ou l'API le permet, une température basse aide pour l'analyse, le factuel et le code stable. Une température plus haute sert mieux le brainstorming, les variantes et la rédaction plus créative.
Repère pratique : - analyse ou factuel : température basse ; - génération de code prudent : température basse ; - idéation ou exploration : température plus haute.
Un méga-prompt mélange souvent extraction, analyse, décision et production finale. Il vaut mieux découper : d'abord extraire, ensuite analyser, enfin produire. Chaque étape peut valider ou corriger la précédente.
Exemple : Prompt 1 : extraire les informations clés. Prompt 2 : analyser ces informations. Prompt 3 : produire la sortie finale à partir de l'analyse.
Avant de considérer la sortie comme exploitable, demandez une vérification interne simple : points traités, contradictions, respect du format, oublis et corrections éventuelles.
Après génération, vérifie : 1) tous les points demandés sont couverts ; 2) aucune contradiction n'apparait ; 3) le format est respecté ; 4) si un point échoue, corrige puis revérifie.
Utiliser l’IA comme partenaire de réflexion
Une demande complexe gagne à séparer le cadrage, l’analyse et la production finale. Ces modèles demandent une synthèse explicite et vérifiable, sans exiger l’affichage d’un raisonnement interne. Remplacez chaque élément entre crochets par votre contexte avant d’envoyer le prompt.
Intérêt : clarifier l’audience, les objections et la structure avant la rédaction évite un contenu générique.
Je dois créer [TYPE DE CONTENU] pour [PUBLIC] afin d’obtenir [RÉSULTAT ATTENDU]. Avant de rédiger, prépare un cadrage concis : - besoin réel du public ; - trois à cinq angles pertinents ; - objections ou questions probables ; - informations manquantes ; - structure recommandée et critères de réussite. Signale tes hypothèses, recommande une direction avec une justification courte, puis produis le contenu final. Évite les généralités.
Intérêt : un brief intermédiaire rend visibles les ambiguïtés avant qu’elles contaminent le livrable.
Voici mon idée brute : [IDÉE]. Ne l’exécute pas immédiatement. Transforme-la en brief professionnel comprenant : objectif, public cible, problème, résultat, message clé, éléments indispensables, contraintes, ton, critères de réussite et livrables. Pose jusqu’à trois questions si une réponse peut changer fortement le résultat. Sinon, formule des hypothèses clairement signalées, puis utilise le brief pour produire [LIVRABLE ATTENDU].
Intérêt : demander une contradiction argumentée aide à repérer les hypothèses fragiles et les coûts cachés.
J’envisage cette décision : [IDÉE OU PROJET]. Contexte : [CONTEXTE]. Contraintes : [CONTRAINTES]. Agis comme un conseiller critique dont le rôle est d’améliorer la décision, pas de me donner raison. Analyse : - les hypothèses sans preuve ; - les causes possibles d’échec ; - les éléments négligés ; - une alternative crédible ; - les validations nécessaires avant d’investir davantage. Recommande ensuite une option et trois prochaines actions réversibles.
Intérêt : distinguer symptômes et causes profondes réduit les corrections superficielles.
Voici un problème concernant [TEXTE / CODE / PROCESSUS / DESIGN] : [CONTENU ET SYMPTÔMES OBSERVÉS]. Avant toute correction, établis un diagnostic : 1. symptômes observables ; 2. causes possibles, avec preuves ou informations manquantes ; 3. impact de chaque problème ; 4. ordre de priorité. Propose ensuite une version améliorée et explique les trois changements les plus importants. Distingue les faits des hypothèses.
Intérêt : imposer des approches distinctes évite de recevoir trois variantes superficielles de la même solution.
Je veux atteindre [OBJECTIF]. Situation : [CONTEXTE]. Contraintes : [BUDGET / TEMPS / OUTILS / ÉQUIPE]. Propose trois approches fondamentalement différentes. Pour chacune, compare : effort, bénéfice probable, risque principal, délai avant résultat, dépendances et profil auquel elle convient. Présente la comparaison dans un tableau, recommande une approche pour mon contexte et transforme-la en plan de mise en œuvre par étapes.
Intérêt : des critères explicites produisent un retour plus précis qu’une simple demande d’amélioration.
Évalue ce [CONTENU OU PROPOSITION] comme un [RÔLE EXPERT] : [CONTENU]. Public et objectif : [CONTEXTE]. Note de 1 à 10, avec une preuve, la clarté, la persuasion, l’utilité, la différenciation et l’adéquation au public. Pour chaque note inférieure à 9, indique la faiblesse exacte et une amélioration concrète. Crée ensuite une version renforcée qui conserve mon intention et récapitule les modifications appliquées.
Intérêt : quelques questions ciblées révèlent souvent un manque que la demande initiale ne permettait pas de voir.
Mon objectif : [OBJECTIF]. Voici le contexte disponible : [CONTEXTE]. Avant de proposer une solution, formule les cinq questions qu’un spécialiste poserait. Pour chacune, explique brièvement comment la réponse pourrait modifier la recommandation. Pose-moi d’abord les questions réellement bloquantes. Pour les autres, utilise si nécessaire des hypothèses prudentes et signalées, puis propose la recommandation la mieux étayée.
Intérêt : une matrice pondérée rend les préférences et les compromis discutables plutôt qu’implicites.
Je dois choisir entre [OPTION A], [OPTION B] et [OPTION C]. Mes priorités : [PRIORITÉS]. Mes contraintes : [CONTRAINTES]. Propose les critères utiles, demande-moi de confirmer leur poids, puis construis un tableau de décision. Pour chaque note, donne une justification et indique le niveau d’incertitude. Signale les compromis cachés, recommande une option et termine par : « Choisissez A si… ; choisissez B si… ; choisissez C si… ».
Intérêt : des rôles complémentaires font apparaître différents risques, sans prétendre remplacer de vrais spécialistes.
Analyse [IDÉE / PLAN / CONTENU] selon trois perspectives : - [PERSPECTIVE 1] ; - [PERSPECTIVE 2] ; - un observateur extérieur sceptique. Pour chaque perspective, indique forces, faiblesses, questions et premier changement recommandé. Compare ensuite leurs accords et désaccords, puis produis une synthèse priorisée. Présente ces avis comme une méthode d’analyse simulée, pas comme l’opinion de professionnels réellement consultés.
Intérêt : appliquer le principe de Pareto aide à réduire une liste trop longue aux actions qui méritent réellement l’effort.
Voici les actions envisagées pour [OBJECTIF] : [LISTE]. Contexte et contraintes : [CONTEXTE]. Identifie les quelques actions susceptibles de produire l’essentiel du résultat. Pour chacune, explique l’impact attendu, l’effort, les dépendances et la preuve qui permettra de valider l’effet. Indique ce qui peut être reporté ou abandonné, les risques de ce choix, puis construis un plan limité aux deux ou trois priorités de la semaine.
Ces modèles peuvent s’enchaîner : construisez d’abord un brief, challengez ensuite les hypothèses, comparez les options, puis terminez par une critique et une priorisation. Une réponse de l’IA reste une aide à la décision : vérifiez les faits et gardez la responsabilité du choix final.
Cas du site
- Contraintes négatives : sur save-fiche.php, demander de ne pas changer l'API ni le format JSON de sortie.
- Sortie stricte : pour DEPLOIEMENT.md, imposer un format type prérequis, étapes, contrôles, retour arrière.
- Chaînage : pour fiches.json, faire extraction des anomalies, analyse des causes, puis plan de correction.
- Vérification finale : sur start-admin.ps1, demander prérequis, erreurs possibles et contrôles de fin de procédure.
Quel conseil choisir en premier
- La réponse part dans tous les sens : commencer par les contraintes négatives et la structure de sortie.
- La réponse va trop vite : imposer une analyse courte avant la conclusion.
- Le format n'est pas fiable : utiliser un gabarit strict ou un balisage simple.
- La demande est trop lourde : découper en plusieurs prompts avec validation intermédiaire.
- Le résultat est incohérent : ajouter une boucle d'auto-vérification finale.
Erreurs fréquentes même avec ces techniques
- Contraintes trop nombreuses : empiler tellement d'interdits que la tâche devient illisible.
- Few-shot trompeur : donner un exemple trop spécifique qui force une imitation pauvre au lieu d'une vraie méthode.
- Format trop rigide : exiger un balisage inutile quand une checklist ou un plan suffirait.
- Chaînage mal coupé : séparer les étapes, mais oublier de reporter les conclusions utiles d'une étape à l'autre.
- Auto-vérification cosmétique : demander "verifie" sans dire quoi contrôler ni quoi faire en cas d'échec.
Version débutant vers intermédiaire
- Débutant : commencer par les points 1, 3 et 8 : interdits, format, vérification.
- Intermédiaire : ajouter les points 2, 5 et 7 : plan d'analyse, séparation du cadre et chaînage des prompts.
- Plus avancé : utiliser few-shot méthodique et température adaptée quand l'outil le permet.
Pages voisines utiles
Voir les bonnes pratiques, bien structurer un prompt, les anti-patterns, les sorties attendues, les exemples avant / après, les squelettes de prompts et Copilot / VS Code avancé.