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.
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é.