Ingénierie de prompts
Chaîner des prompts complexes pour de meilleures performances
Premiers pas
Modèles et tarifs
Explorer les fonctionnalités
En savoir plus sur Claude
- Construire avec Claude
- Cas d'utilisation
- Fenêtres de contexte
- Glossaire
- Ingénierie de prompts
- Vue d'ensemble
- Meilleures pratiques pour Claude 4
- Générateur de prompts
- Utiliser des modèles de prompts
- Améliorateur de prompts
- Soyez clair et direct
- Utiliser des exemples (prompting multishot)
- Laissez Claude réfléchir (CoT)
- Utiliser les balises XML
- Donner un rôle à Claude (invites système)
- Préremplir la réponse de Claude
- Chaîner des prompts complexes
- Conseils contexte long
- Conseils pour la réflexion approfondie
Centre juridique
Tester et évaluer
- Définir les critères de réussite
- Développer des cas de test
- Renforcer les garde-fous
- Utilisation de l'outil d'évaluation
Composants d'agent
- Outils
- Protocole de Contexte du Modèle (MCP)
- Utilisation d'ordinateur (bêta)
- Extension Google Sheets
Ingénierie de prompts
Chaîner des prompts complexes pour de meilleures performances
While these tips apply broadly to all Claude models, you can find prompting tips specific to extended thinking models here.
Lorsque vous travaillez sur des tâches complexes, Claude peut parfois perdre le fil si vous essayez de tout gérer dans un seul prompt. Le prompt de chaîne de pensée (Chain of Thought - CoT) est excellent, mais que faire si votre tâche comporte plusieurs étapes distinctes nécessitant chacune une réflexion approfondie ?
Voici le chaînage de prompts : décomposer des tâches complexes en sous-tâches plus petites et gérables.
Pourquoi chaîner les prompts ?
- Précision : Chaque sous-tâche reçoit toute l’attention de Claude, réduisant les erreurs.
- Clarté : Des sous-tâches plus simples signifient des instructions et des résultats plus clairs.
- Traçabilité : Identifiez et corrigez facilement les problèmes dans votre chaîne de prompts.
Quand chaîner les prompts
Utilisez le chaînage de prompts pour les tâches en plusieurs étapes comme la synthèse de recherche, l’analyse de documents ou la création itérative de contenu. Lorsqu’une tâche implique plusieurs transformations, citations ou instructions, le chaînage empêche Claude de sauter ou de mal gérer des étapes.
Rappel : Chaque maillon de la chaîne reçoit toute l’attention de Claude !
Conseil de débogage : Si Claude manque une étape ou performe mal, isolez cette étape dans son propre prompt. Cela vous permet d’affiner les étapes problématiques sans refaire toute la tâche.
Comment chaîner les prompts
- Identifier les sous-tâches : Décomposez votre tâche en étapes distinctes et séquentielles.
- Structurer avec XML pour des transferts clairs : Utilisez des balises XML pour transmettre les sorties entre les prompts.
- Avoir un objectif à tâche unique : Chaque sous-tâche doit avoir un objectif unique et clair.
- Itérer : Affinez les sous-tâches en fonction des performances de Claude.
Exemples de flux de travail chaînés :
- Analyse en plusieurs étapes : Voir les exemples juridiques et commerciaux ci-dessous.
- Pipelines de création de contenu : Recherche → Plan → Brouillon → Édition → Formatage.
- Traitement des données : Extraction → Transformation → Analyse → Visualisation.
- Prise de décision : Recueillir les infos → Lister les options → Analyser chacune → Recommander.
- Boucles de vérification : Générer du contenu → Réviser → Affiner → Re-réviser.
Conseil d’optimisation : Pour les tâches avec des sous-tâches indépendantes (comme l’analyse de plusieurs documents), créez des prompts séparés et exécutez-les en parallèle pour plus de rapidité.
Avancé : Chaînes d’auto-correction
Vous pouvez chaîner des prompts pour que Claude révise son propre travail ! Cela permet de détecter les erreurs et d’affiner les résultats, en particulier pour les tâches à enjeux élevés.
Prompt 1
| Rôle | Contenu |
|---|---|
| User | Résumez cet article de recherche médicale. <paper>{{RESEARCH_PAPER}}</paper> Concentrez-vous sur la méthodologie, les résultats et les implications cliniques. |
| Assistant {{SUMMARY}} | Méthodologie : ECR en double aveugle avec 500 patients diabétiques de type 2. Groupe A (n=250) a reçu un nouvel agoniste double GLP-1/GIP ; Groupe B (n=250) a reçu un agoniste GLP-1 standard. Essai de 24 semaines, critère principal : réduction de l’HbA1c. Résultats : - Groupe A : réduction moyenne de l’HbA1c de 1,8% - Groupe B : réduction moyenne de l’HbA1c de 1,1% - 68% du Groupe A vs 52% du Groupe B ont atteint une HbA1c <7% - Groupe A : perte de poids moyenne de 5,2kg - Groupe B : perte de poids moyenne de 3,1kg Sécurité : Profils d’événements indésirables similaires, aucun événement grave attribué au traitement. Implications cliniques : L’agoniste double montre un contrôle glycémique et une perte de poids supérieurs par rapport à la thérapie standard. Pourrait être révolutionnaire, en particulier pour les diabétiques obèses. |
Prompt 2
| Rôle | Contenu |
|---|---|
| User | Votre tâche est de fournir un retour sur un résumé d’article de recherche. Voici un résumé d’un article de recherche médicale : <summary> {{SUMMARY}} </summary> Voici l’article de recherche : <paper> {{RESEARCH_PAPER}} </paper> Évaluez ce résumé pour son exactitude, sa clarté et son exhaustivité sur une échelle de A à F. |
| Assistant {{FEEDBACK}} | 1. Exactitude : A - Statistiques clés correctement rapportées : réductions d’HbA1c, perte de poids. - Profil de sécurité et absence d’événements indésirables graves notés avec précision. - L’affirmation “révolutionnaire” est justifiée par des résultats significativement meilleurs. 2. Clarté : A- - Concis et bien structuré avec des sections claires. - Bon usage du langage comparatif (ex : “en hausse de 3% par rapport au T1”) pour le contexte. - Problème mineur : Acronymes comme “ECR”, “GLP-1” et “GIP” non définis. Envisager de les écrire en entier à la première utilisation. 3. Exhaustivité : B+ - Couvre tous les domaines demandés : méthodologie, résultats, implications cliniques. - Manquant : Caractéristiques de base des groupes (étaient-ils bien appariés ?). - Manquant : Critères d’évaluation secondaires (ex : tension artérielle, lipides). - À considérer : Implications à long terme ou besoin de recherches supplémentaires. Globalement, le résumé est précis et clair, fournissant des aperçus clés pour une compréhension rapide de l’étude. Pour atteindre A+, définir les acronymes, mentionner les statistiques de base des groupes, noter les résultats secondaires et aborder brièvement le besoin d’études à long terme. |
Prompt 3
| Rôle | Contenu |
|---|---|
| User | Votre tâche est d’améliorer un résumé d’article selon les retours. Voici la première version d’un résumé d’article de recherche médicale : <summary> {{SUMMARY}} </summary> Voici l’article de recherche : <paper> {{RESEARCH_PAPER}} </paper> Voici les retours : <feedback> {{FEEDBACK}} </feedback> Mettez à jour le résumé en fonction des retours. |
| Assistant | Méthodologie : Essai contrôlé randomisé (ECR) en double aveugle avec 500 patients diabétiques de type 2. Groupe A (n=250) a reçu un nouvel agoniste double peptide-1 de type glucagon/polypeptide insulinotrope glucose-dépendant (GLP-1/GIP) ; Groupe B (n=250) a reçu un agoniste GLP-1 standard. L’essai de 24 semaines avait pour critère principal la réduction de l’HbA1c. Les groupes étaient bien appariés pour l’âge, l’IMC et l’HbA1c de base. Résultats : - Groupe A : réduction moyenne de l’HbA1c de 1,8% - Groupe B : réduction moyenne de l’HbA1c de 1,1% - 68% du Groupe A vs 52% du Groupe B ont atteint une HbA1c <7% - Groupe A : perte de poids moyenne de 5,2kg - Groupe B : perte de poids moyenne de 3,1kg Les critères d’évaluation secondaires ont montré des améliorations de la tension artérielle et des profils lipidiques dans les deux groupes, le Groupe A montrant des résultats légèrement meilleurs. Sécurité : Profils d’événements indésirables similaires, sans événements graves attribués à l’un ou l’autre traitement. Implications cliniques : L’agoniste double GLP-1/GIP démontre un contrôle glycémique et une perte de poids supérieurs par rapport à la thérapie GLP-1 standard. Ces résultats suggèrent qu’il pourrait constituer une avancée significative, particulièrement pour les diabétiques obèses. Cependant, des études à plus long terme sont nécessaires pour confirmer l’efficacité et la sécurité durables, ainsi que pour étudier les bénéfices potentiels sur les résultats cardiovasculaires. |
Exemples
Notez que Claude manque l’instruction de fournir des modifications proposées dans son projet d’e-mail.
| Rôle | Contenu |
|---|---|
| User | Vous êtes notre Directeur Juridique. Examinez ce contrat SaaS pour les risques, en vous concentrant sur la confidentialité des données, les SLA et les plafonds de responsabilité. <contract> {{CONTRACT}} </contract> Puis rédigez un e-mail au fournisseur avec vos préoccupations et les modifications proposées. |
| Assistant | Après examen du contrat SaaS, j’ai identifié plusieurs préoccupations : 1. Confidentialité des données (Section 7) : - Problème : Le fournisseur a des droits étendus d’utilisation des données client pour “l’amélioration du service”. - Risque : Pourrait conduire à un partage ou une monétisation non autorisés des données. 2. SLA (Section 5) : - Problème : Garantie de disponibilité de 99,5% inférieure aux standards du secteur. - Risque : Une indisponibilité excessive pourrait impacter nos opérations. 3. Responsabilité (Section 9) : - Problème : Plafond fixé à 3 mois de frais. - Risque : Inadéquat pour les violations de données ou pannes de service potentielles. Projet d’e-mail : Cher {{VENDOR}}, Après examen de l’accord SaaS, nous avons des préoccupations : 1. Confidentialité des données : Nous exigeons que nos données soient uniquement utilisées pour la fourniture directe du service, pas pour une large “amélioration du service”. Veuillez modifier la Section 7. 2. SLA : 99,5% de disponibilité est insuffisant. Nous avons besoin de 99,99% avec des pénalités clairement définies. Veuillez réviser la Section 5. 3. Responsabilité : Le plafond actuel de 3 mois de frais est inadéquat. Nous proposons un plafond de 12 mois de frais, sans plafond pour les violations de données ou fautes intentionnelles. Nous apprécions notre partenariat potentiel et pensons que ces changements nous mettront sur la voie du succès. Merci d’envoyer un accord révisé. Cordialement, {{CLO_NAME}} |
Prompt 1
| Rôle | Contenu |
|---|---|
| User | Vous êtes notre Directeur Juridique. Examinez ce contrat SaaS pour les risques, en vous concentrant sur la confidentialité des données, les SLA et les plafonds de responsabilité. <contract> {{CONTRACT}} </contract> Présentez vos conclusions dans des balises <risks>. |
| Assistant {{CONCERNS}} | 1. Confidentialité des données (Section 7) : - Problème : Le fournisseur a des droits étendus d’utilisation des données client pour “l’amélioration du service”. - Risque : Pourrait conduire à un partage ou une monétisation non autorisés des données client. - Impact : Violation potentielle de la confiance client, amendes réglementaires (RGPD, CCPA). 2. SLA (Section 5) : - Problème : Garantie de disponibilité de 99,5% inférieure aux standards du secteur (typiquement 99,99%). - Risque : Jusqu’à 43,8 heures d’indisponibilité par an contre 52,6 minutes à 99,99%. - Impact : Perturbations opérationnelles, perte de revenus, insatisfaction client. 3. Responsabilité (Section 9) : - Problème : Plafond de responsabilité fixé à 3 mois de frais. - Risque : Inadéquat pour les violations de données potentielles, vol de PI ou pannes de service prolongées. - Impact : Indemnisation insuffisante pour des dommages qui pourraient largement dépasser le plafond, comme les recours collectifs ou amendes réglementaires. |
Prompt 2
| Rôle | Contenu |
|---|---|
| User | Rédigez un e-mail à un fournisseur de produit SaaS exposant les préoccupations suivantes et proposant des modifications. Voici les préoccupations : <concerns> {{CONCERNS}} </concerns> |
| Assistant {{EMAIL}} | Cher {{VENDOR}}, Après un examen approfondi de l’accord SaaS proposé, notre équipe juridique a identifié plusieurs préoccupations prioritaires qui doivent être traitées avant que nous puissions procéder : 1. Confidentialité des données (Section 7) : - Actuel : Droits étendus d’utilisation des données client pour “l’amélioration du service”. - Préoccupation : Partage ou monétisation non autorisés potentiels. - Modification proposée : Limiter l’utilisation des données à la fourniture directe du service. Toute utilisation pour l’amélioration, l’analyse ou le marketing doit être optionnelle, révocable et anonymisée. 2. SLA (Section 5) : - Actuel : Garantie de disponibilité de 99,5%. - Préoccupation : Jusqu’à 43,8 heures d’indisponibilité par an, risquant des perturbations opérationnelles. - Modification proposée : 99,99% de disponibilité avec crédits de service échelonnés. Ex : 10% de crédit pour <99,99%, 25% pour <99,9%, 50% pour <99,5%. 3. Responsabilité (Section 9) : - Actuel : Plafond à 3 mois de frais. - Préoccupation : Grossièrement inadéquat pour les violations de données, vol de PI ou pannes prolongées. - Modification proposée : 12 mois de frais pour la responsabilité générale. Sans plafond pour les violations de données, faute intentionnelle, violation de PI. Ces modifications sont non négociables pour nous. Elles s’alignent sur les standards du secteur et notre engagement envers la sécurité des données, l’excellence opérationnelle et la responsabilité fiduciaire. Nous apprécions le potentiel de notre partenariat, et traiter ces points établira une base solide. Veuillez faire examiner et incorporer ces modifications par votre équipe juridique. Nous sommes disponibles pour en discuter davantage afin d’assurer une compréhension et un accord mutuels. Cordialement, {{CLO_NAME}} |
Prompt 3
| Rôle | Contenu |
|---|---|
| User | Votre tâche est d’examiner un e-mail et de fournir des retours. Voici l’e-mail : <email> {{EMAIL}} </email> Donnez des retours sur le ton, la clarté et le professionnalisme. |
| Assistant | 1. Ton : - Professionnel et assertif sans être confrontationnel. - L’utilisation de “non négociables” est forte mais justifiée étant donné la criticité des problèmes. - Le langage collaboratif (“nous apprécions”, “disponibles pour en discuter”) équilibre la fermeté, maintenant un ton constructif. 2. Clarté : - Excellente structuration : État actuel, préoccupation et modification proposée pour chaque problème. - Les termes techniques (ex : “EBITDA”, “crédits de service échelonnés”) sont appropriés pour un contexte SaaS B2B. - Les actions à entreprendre sont claires : l’équipe juridique du fournisseur doit examiner et incorporer les modifications. 3. Professionnalisme : - Se concentre sur le bénéfice mutuel et les standards du secteur, pas seulement sur nos exigences. - Mentionne des responsabilités plus larges (sécurité des données, excellence opérationnelle, devoir fiduciaire), élevant la discussion. - Offre une discussion ultérieure, montrant l’engagement à comprendre et résoudre les problèmes. Globalement, l’e-mail trouve le bon équilibre entre assertivité et collaboration. Il articule clairement nos préoccupations, propose des solutions spécifiques et maintient un ton professionnel orienté partenariat. Aucune révision nécessaire ; procéder à l’envoi. |
Prompt 1
| Rôle | Contenu |
|---|---|
| User | En tant qu’architecte solutions senior, examinez et analysez cette stratégie multi-locataire pour notre nouveau produit SaaS entreprise. <strategy> {{STRATEGY}} </strategy> Concentrez-vous sur l’évolutivité, la sécurité et la rentabilité. |
| Assistant {{ANALYSIS}} | 1. Évolutivité : + Le partitionnement de base de données par locataire réduit la contention, supporte une forte croissance. + Les microservices permettent une mise à l’échelle indépendante des composants. - Les serveurs d’application partagés pourraient créer un goulot d’étranglement sous charge extrême. - Pas de mention d’auto-scaling ou d’équilibrage de charge pour la couche applicative. 2. Sécurité : + L’isolation des données des locataires via le partitionnement atténue les fuites de données. + JWT avec expiration courte et tokens de rafraîchissement est une meilleure pratique du secteur. - Pas de mention du chiffrement (au repos, en transit) ou de la gestion des clés. - La stratégie IAM manque de détails sur les rôles, permissions ou RBAC. 3. Rentabilité : + Les serveurs d’application partagés réduisent les coûts des ressources inactives. + Les fonctions serverless pour les tâches peu fréquentes optimisent les coûts. - La BD par locataire pourrait augmenter les coûts à l’échelle vs une BD multi-locataire optimisée. - Pas de discussion sur les instances réservées ou spot pour l’économie de coûts. |
Prompt 2
| Rôle | Contenu |
|---|---|
| User | Rédigez un document de revue de stratégie pour la direction technique basé sur cette analyse d’une stratégie multi-locataire. <strategy> {{STRATEGY}} </strategy> <analysis> {{ANALYSIS}} </analysis> Incluez un résumé exécutif, une analyse détaillée et des recommandations. |
| Assistant {{STRATEGY_DOC}} | # Revue de Stratégie Multi-locataire : Produit SaaS Entreprise ## Résumé Exécutif La stratégie proposée démontre une base solide en principes d’évolutivité et de sécurité mais présente des lacunes dans les détails d’implémentation. Elle excelle en isolation des données et mise à l’échelle des composants mais manque de robustesse pour la mise à l’échelle de la couche applicative et les mesures de sécurité avancées. Les optimisations de coûts sont présentes mais pourraient faiblir à grande échelle. Avec des améliorations ciblées, cette stratégie peut efficacement soutenir nos ambitions SaaS entreprise. ## Analyse Détaillée ### 1. Évolutivité : B+ Forces : - Le partitionnement de base de données par locataire est excellent. Il minimise la latence des requêtes, supporte une forte croissance des données et facilite la mise à l’échelle transparente par locataire. - L’architecture microservices permet la mise à l’échelle de composants individuels selon la demande, crucial pour gérer des charges de travail d’entreprise diverses. Faiblesses : - Les serveurs d’application partagés risquent de devenir un goulot d’étranglement. Avec la croissance du nombre de locataires et du trafic, cela pourrait dégrader les performances pour tous les locataires. - L’absence d’auto-scaling et d’équilibrage de charge pour la couche applicative est une omission critique. Ces éléments sont essentiels pour gérer les pics de trafic sans sur-provisionnement. ### 2. Sécurité : B- Forces : - Les bases de données partitionnées fournissent une forte isolation des données des locataires, atténuant les risques de fuites de données ou d’accès non autorisé entre locataires. - JWT avec expiration courte et tokens de rafraîchissement s’alignent sur les meilleures pratiques OWASP, réduisant les fenêtres de vulnérabilité des tokens. Faiblesses : - Pas de mention du chiffrement des données au repos ou en transit (TLS 1.3). C’est non négociable pour les données d’entreprise. - La stratégie de gestion des clés est manquante. Comment sont gérées et rotées les clés de chiffrement, secrets JWT et identifiants BD ? - L’IAM manque de profondeur. Nous avons besoin de RBAC avec des rôles bien définis, contrôle d’accès basé sur les attributs (ABAC) pour des permissions fines, et intégration avec les fournisseurs d’identité d’entreprise (SAML, OIDC). ### 3. Rentabilité : B Forces : - Les serveurs d’application partagés réduisent les coûts de capacité inactive, bon pour le trafic en régime permanent. - Le serverless pour les tâches peu fréquentes (ex : reporting) est intelligent ; paiement uniquement lors de l’utilisation de ces ressources. Faiblesses : - Les bases de données par locataire peuvent ne pas être rentables à l’échelle comparées à une base de données multi-locataire bien conçue avec un partitionnement robuste des données. - Pas de mention de mesures d’économie de coûts comme les instances réservées pour les charges prévisibles ou les instances spot pour les tâches tolérantes aux pannes. - L’absence d’auto-scaling de la couche applicative pourrait conduire au sur-provisionnement, augmentant les coûts. ## Recommandations 1. Résilience de la Couche Applicative : Implémenter l’auto-scaling avec Kubernetes ou services cloud natifs (EKS, GKE). Déployer à travers les zones de disponibilité avec un CDN pour les assets statiques. 2. Renforcement de la Sécurité : a. Chiffrer les données au repos (AES-256) et en transit (TLS 1.3). b. Utiliser un KMS géré (AWS KMS, GCP KMS) pour la gestion des clés. c. Améliorer l’IAM avec RBAC, ABAC et SAML/OIDC pour SSO entreprise. 3. Optimisation des Coûts : a. Évaluer BD multi-locataire colonnaire (ex : Snowflake) vs partitionnement à l’échelle. b. Utiliser instances réservées pour serveurs d’application, instances spot pour charges non critiques. c. Implémenter monitoring proactif et dimensionnement correct pour éviter le sur-provisionnement. 4. Preuve de Concept (PoC) : Avant l’implémentation complète, conduire une PoC avec simulation haute échelle : a. Tester BD partitionnée vs BD multi-locataire optimisée pour coût et performance. b. Tester en charge la couche applicative avec pics de trafic simulés niveau entreprise. c. Conduire audit sécurité tiers, focus sur isolation données et contrôles d’accès. Avec ces améliorations, notre stratégie multi-locataire sera niveau entreprise : évolutive, sécurisée et rentable. La PoC validera nos choix de conception et inspirera confiance à nos clients entreprise. |
Prompt 3
| Rôle | Contenu |
|---|---|
| User | Évaluez ce document de revue de stratégie pour la clarté, l’actionnabilité et l’alignement avec les priorités entreprise. <priorities> {{PRIORITIES}} </priorities> <strategy_doc> {{STRATEGY_DOC}} </strategy_doc> |
| Assistant | 1. Clarté : A + Structure claire avec Résumé Exécutif, Analyse Détaillée et Recommandations. + L’analyse utilise un système de notation (B+, B-) pour une compréhension rapide des forces/faiblesses. + Les termes techniques (RBAC, ABAC, TLS) sont expliqués ou contextualisés, aidant la direction non technique. + Les aides visuelles (puces, indentation) améliorent la lisibilité. 2. Actionnabilité : A- + Les recommandations sont spécifiques et techniques (ex : “Implémenter l’auto-scaling avec Kubernetes”). + Le plan PoC avec des objectifs clairs fournit une feuille de route. - Manquant : Calendriers, besoins en ressources ou assignations d’équipe pour chaque recommandation. + À considérer : Ajouter une section “Prochaines Étapes” avec actions immédiates, rôles et calendrier de haut niveau. 3. Alignement Entreprise : A+ + Adresse directement les priorités entreprise : - Évolutivité : Discute la gestion des pics de trafic niveau entreprise. - Sécurité : Focus sur isolation données, chiffrement et IAM entreprise. - Coût : Stratégies alignées avec FinOps entreprise (instances réservées, dimensionnement correct). + PoC avec “simulation haute échelle” et audit sécurité montre l’engagement pour la qualité niveau entreprise. + Le langage résonne avec les préoccupations entreprise : “risque inacceptable”, “niveau entreprise”, “inspirer confiance”. Globalement, le document excelle en clarté et alignement entreprise. L’actionnabilité est forte mais pourrait être élevée à A+ avec une section “Prochaines Étapes”. La profondeur technique, couplée à des explications claires, rend ceci hautement efficace pour la direction technique et non technique. Excellent travail ! |
Bibliothèque de prompts
Inspirez-vous d’une sélection organisée de prompts pour diverses tâches et cas d’utilisation.
Tutoriel de prompting GitHub
Un tutoriel rempli d’exemples qui couvre les concepts d’ingénierie de prompts trouvés dans notre documentation.
Tutoriel de prompting Google Sheets
Une version plus légère de notre tutoriel d’ingénierie de prompts via une feuille de calcul interactive.
Was this page helpful?