While these tips apply broadly to all Claude models, you can find prompting tips specific to extended thinking models here.
Pourquoi enchaî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 enchaîner les prompts
Utilisez l’enchaînement de prompts pour des tâches multi-étapes comme la synthèse de recherche, l’analyse de documents ou la création de contenu itérative. Lorsqu’une tâche implique plusieurs transformations, citations ou instructions, l’enchaînement empêche Claude d’omettre ou de mal gérer les étapes. Rappelez-vous : 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 enchaîner les prompts
- Identifiez les sous-tâches : Décomposez votre tâche en étapes distinctes et séquentielles.
- Structurez avec XML pour des transitions claires : Utilisez des balises XML pour transmettre les résultats entre les prompts.
- Ayez un objectif de tâche unique : Chaque sous-tâche devrait avoir un objectif unique et clair.
- Itérez : Affinez les sous-tâches en fonction des performances de Claude.
Exemples de flux de travail enchaînés :
- Analyse multi-étapes : Voir les exemples juridiques et commerciaux ci-dessous.
- Pipelines de création de contenu : Recherche → Plan → Brouillon → Édition → Format.
- Traitement de données : Extraire → Transformer → Analyser → Visualiser.
- Prise de décision : Rassembler 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 analyser plusieurs documents), créez des prompts séparés et exécutez-les en parallèle pour la vitesse.
Avancé : Chaînes d’auto-correction
Vous pouvez enchaîner des prompts pour que Claude révise son propre travail ! Cela détecte les erreurs et affine les résultats, surtout pour les tâches à enjeux élevés.Exemple : Résumé de recherche auto-correcteur
Exemple : Résumé de recherche auto-correcteur
Prompt 1
| Rôle | Contenu |
|---|---|
| Utilisateur | 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 dual 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 : 1,8% de réduction moyenne de l’HbA1c - Groupe B : 1,1% de réduction moyenne de l’HbA1c - 68% du Groupe A vs 52% du Groupe B ont atteint HbA1c <7% - Groupe A : 5,2kg de perte de poids moyenne - Groupe B : 3,1kg de perte de poids moyenne Sécurité : Profils d’événements indésirables similaires, aucun événement grave attribué au traitement. Implications Cliniques : L’agoniste dual montre un contrôle glycémique et une perte de poids supérieurs par rapport à la thérapie standard. Pourrait être révolutionnaire, surtout pour les diabétiques obèses. |
Prompt 2
| Rôle | Contenu |
|---|---|
| Utilisateur | Votre tâche est de fournir des commentaires 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 la précision, la clarté et l’exhaustivité sur une échelle graduée A-F. |
| Assistant {{FEEDBACK}} | 1. Précision : 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 correctement notés. - L’affirmation de “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. “hausse de 3% par rapport au T1”) pour le contexte. - Problème mineur : Acronymes comme “ECR”, “GLP-1” et “GIP” non définis. Considérez l’épellation complète à la première utilisation. 3. Exhaustivité : B+ - Couvre tous les domaines demandés : méthodologie, résultats, implications cliniques. - Manque : Caractéristiques de base des groupes (étaient-ils bien appariés ?). - Manque : Critères secondaires (ex. pression artérielle, lipides). - À considérer : Implications à long terme ou besoin de recherches supplémentaires. Dans l’ensemble, le résumé est précis et clair, fournissant des insights 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 |
|---|---|
| Utilisateur | Votre tâche est d’améliorer un résumé d’article selon les commentaires. Voici le premier brouillon d’un article de recherche médicale : <summary> {{SUMMARY}} </summary> Voici l’article de recherche : <paper> {{RESEARCH_PAPER}} </paper> Voici les commentaires : <feedback> {{FEEDBACK}} </feedback> Mettez à jour le résumé basé sur les commentaires. |
| 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 dual 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. Le critère principal de l’essai de 24 semaines était 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 : 1,8% de réduction moyenne de l’HbA1c - Groupe B : 1,1% de réduction moyenne de l’HbA1c - 68% du Groupe A vs 52% du Groupe B ont atteint HbA1c <7% - Groupe A : 5,2kg de perte de poids moyenne - Groupe B : 3,1kg de perte de poids moyenne Les critères secondaires ont montré des améliorations de la pression artérielle et des profils lipidiques pour 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 dual 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 être 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é soutenues, ainsi que pour investiguer les bénéfices potentiels sur les résultats cardiovasculaires. |
Exemples
Exemple : Analyser un contrat juridique (sans enchaînement)
Exemple : Analyser un contrat juridique (sans enchaînement)
Notez que Claude manque l’instruction de fournir des changements proposés dans son brouillon d’email.
| Rôle | Contenu |
|---|---|
| Utilisateur | 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 email au fournisseur avec vos préoccupations et les changements proposés. |
| Assistant | Après avoir examiné le contrat SaaS, j’ai identifié plusieurs préoccupations : 1. Confidentialité des Données (Section 7) : - Problème : Le fournisseur a de larges droits d’utiliser les données client pour “l’amélioration du service”. - Risque : Pourrait mener au partage non autorisé de données ou à la monétisation. 2. SLA (Section 5) : - Problème : Garantie de disponibilité de 99,5% est en dessous du standard de l’industrie. - Risque : Temps d’arrêt excessif 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 potentielles ou les défaillances de service. Brouillon d’email : Cher {{VENDOR}}, Après avoir examiné l’accord SaaS, nous avons des préoccupations : 1. Confidentialité des Données : Nous exigeons que nos données ne soient utilisées que 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 la faute intentionnelle. Nous valorisons notre partenariat potentiel et croyons que ces changements nous prépareront au succès. Veuillez envoyer un accord révisé. Meilleures salutations, {{CLO_NAME}} |
Exemple : Analyser un contrat juridique (avec enchaînement)
Exemple : Analyser un contrat juridique (avec enchaînement)
Prompt 1
| Rôle | Contenu |
|---|---|
| Utilisateur | 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 de larges droits d’utiliser les données client pour “l’amélioration du service”. - Risque : Pourrait mener au partage non autorisé de données ou à la monétisation 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% est en dessous du standard de l’industrie (typiquement 99,99%). - Risque : Jusqu’à 43,8 heures d’arrêt par an vs 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, le vol de PI, ou les défaillances de service prolongées. - Impact : Compensation insuffisante pour les dommages qui pourraient largement dépasser le plafond, comme les recours collectifs ou les amendes réglementaires. |
Prompt 2
| Rôle | Contenu |
|---|---|
| Utilisateur | Rédigez un email à un fournisseur de produit SaaS décrivant les préoccupations suivantes et proposant des changements. 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 de haute priorité qui doivent être adressées avant que nous puissions procéder : 1. Confidentialité des Données (Section 7) : - Actuel : Larges droits d’utiliser les données client pour “l’amélioration du service”. - Préoccupation : Partage non autorisé de données ou monétisation potentielle. - Changement Proposé : Limiter l’utilisation des données à la fourniture directe du service. Toute utilisation pour l’amélioration, l’analytique, ou le marketing doit être opt-in, révocable, et anonymisée. 2. SLA (Section 5) : - Actuel : Garantie de disponibilité de 99,5%. - Préoccupation : Jusqu’à 43,8 heures d’arrêt par an, risquant des perturbations opérationnelles. - Changement Proposé : 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, le vol de PI, ou les pannes prolongées. - Changement Proposé : 12 mois de frais pour la responsabilité générale. Sans plafond pour les violations de données, la faute intentionnelle, la contrefaçon de PI. Ces changements sont non-négociables pour nous. Ils s’alignent avec les standards de l’industrie et notre engagement envers la sécurité des données, l’excellence opérationnelle, et la responsabilité fiduciaire. Nous valorisons le potentiel de notre partenariat, et adresser ces points établira une base solide. Veuillez demander à votre équipe juridique d’examiner et d’incorporer ces changements. Nous sommes heureux de discuter davantage pour assurer une compréhension et un accord mutuels. Meilleures salutations, {{CLO_NAME}} |
Prompt 3
| Rôle | Contenu |
|---|---|
| Utilisateur | Votre tâche est d’examiner un email et de fournir des commentaires. Voici l’email : <email> {{EMAIL}} </email> Donnez des commentaires sur le ton, la clarté, et le professionnalisme. |
| Assistant | 1. Ton : - Professionnel et assertif sans être conflictuel. - L’utilisation de “non-négociables” est forte mais justifiée étant donné la criticité des problèmes. - Le langage collaboratif (“nous valorisons”, “heureux de discuter”) équilibre la fermeté, maintenant un ton constructif. 2. Clarté : - Excellente structuration : État actuel, préoccupation, et changement proposé pour chaque problème. - Les termes techniques (ex., “EBITDA”, “crédits de service échelonnés”) sont appropriés pour un contexte SaaS B2B. - Les éléments d’action sont clairs : l’équipe juridique du fournisseur doit examiner et incorporer les changements. 3. Professionnalisme : - Se concentre sur le bénéfice mutuel et les standards de l’industrie, pas seulement nos demandes. - Mentionne des responsabilités plus larges (sécurité des données, excellence opérationnelle, devoir fiduciaire), élevant la discussion. - Offre une discussion supplémentaire, montrant l’engagement à comprendre et résoudre les problèmes. Dans l’ensemble, l’email 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édez à l’envoi. |
Exemple : Révision de stratégie multi-location
Exemple : Révision de stratégie multi-location
Prompt 1
| Rôle | Contenu |
|---|---|
| Utilisateur | En tant qu’architecte de solutions senior, examinez et analysez cette stratégie de multi-location pour notre nouveau produit SaaS d’entreprise. <strategy> {{STRATEGY}} </strategy> Concentrez-vous sur la scalabilité, la sécurité, et la rentabilité. |
| Assistant {{ANALYSIS}} | 1. Scalabilité : + Le sharding de base de données par locataire réduit la contention, supporte une forte croissance. + Les microservices permettent la mise à l’échelle indépendante des composants. - Les serveurs d’application partagés pourraient créer un goulot d’étranglement sous charge extrême. - Aucune mention d’auto-scaling ou d’équilibrage de charge pour la couche applicative. 2. Sécurité : + L’isolation des données de locataire via sharding atténue les fuites de données. + JWT avec expiration courte et tokens de rafraîchissement est une meilleure pratique de l’industrie. - Aucune mention de chiffrement (au repos, en transit) ou de 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 de 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 BD multi-locataire optimisée. - Aucune discussion d’instances réservées ou d’instances spot pour économiser les coûts. |
Prompt 2
| Rôle | Contenu |
|---|---|
| Utilisateur | Rédigez un document de révision de stratégie pour la direction technique basé sur cette analyse d’une stratégie de multi-location. <strategy> {{STRATEGY}} </strategy> <analysis> {{ANALYSIS}} </analysis> Incluez un résumé exécutif, une analyse détaillée, et des recommandations. |
| Assistant {{STRATEGY_DOC}} | # Révision de Stratégie Multi-Location : Produit SaaS d’Entreprise ## Résumé Exécutif La stratégie proposée démontre une base solide dans les principes de scalabilité et de sécurité mais a des lacunes dans les détails d’implémentation. Elle excelle dans l’isolation des données et la mise à l’échelle au niveau des composants mais manque de mise à l’échelle robuste de la couche applicative et de mesures de sécurité avancées. Les optimisations de coûts sont présentes mais peuvent faiblir à grande échelle. Avec des améliorations ciblées, cette stratégie peut efficacement soutenir nos ambitions SaaS d’entreprise. ## Analyse Détaillée ### 1. Scalabilité : B+ Forces : - Le sharding 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 basée sur la demande, crucial pour gérer diverses charges de travail d’entreprise. Faiblesses : - Les serveurs d’application partagés risquent de devenir un goulot d’étranglement. Alors que le nombre de locataires et le trafic augmentent, ceux-ci pourraient dégrader les performances pour tous les locataires. - L’absence d’auto-scaling et d’équilibrage de charge pour la couche applicative est un oubli critique. Ceux-ci sont essentiels pour gérer les pics de trafic sans sur-provisionnement. ### 2. Sécurité : B- Forces : - Les bases de données shardées fournissent une forte isolation des données de locataire, 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 avec les meilleures pratiques OWASP, réduisant les fenêtres de vulnérabilité des tokens. Faiblesses : - Aucune 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 les clés de chiffrement, les secrets JWT, et les identifiants BD sont-ils gérés et pivotés ? - 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 granulaires, 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 état stable. - Serverless pour les tâches peu fréquentes (ex., rapports) est intelligent ; payez seulement quand ces ressources sont utilisées. Faiblesses : - Les bases de données par locataire peuvent ne pas être rentables à l’échelle comparé à une base de données multi-locataire bien conçue avec partitionnement robuste des données. - Aucune mention de mesures d’économie de coûts comme les instances réservées pour les charges de travail prévisibles ou les instances spot pour les tâches tolérantes aux pannes. - Le manque d’auto-scaling de la couche applicative pourrait mener au sur-provisionnement, augmentant les coûts. ## Recommandations 1. Résilience de la Couche Applicative : Implémentez l’auto-scaling avec Kubernetes ou des services cloud-natifs (EKS, GKE). Déployez à travers les zones de disponibilité avec un CDN pour les actifs statiques. 2. Durcissement de la Sécurité : a. Chiffrez les données au repos (AES-256) et en transit (TLS 1.3). b. Utilisez un KMS géré (AWS KMS, GCP KMS) pour la gestion des clés. c. Améliorez l’IAM avec RBAC, ABAC, et SAML/OIDC pour le SSO d’entreprise. 3. Optimisation des Coûts : a. Évaluez la BD multi-locataire colonnaire (ex., Snowflake) vs sharding à l’échelle. b. Utilisez des instances réservées pour les serveurs d’application, instances spot pour les charges de travail non-critiques. c. Implémentez la surveillance proactive et le dimensionnement approprié pour éviter le sur-provisionnement. 4. Preuve de Concept (PoC) : Avant l’implémentation complète, menez une PoC avec une simulation à grande échelle : a. Testez la BD shardée vs BD multi-locataire optimisée pour le coût et la performance. b. Test de stress de la couche applicative avec des pics de trafic simulés au niveau entreprise. c. Menez un audit de sécurité tiers, se concentrant sur l’isolation des données et les contrôles d’accès. Avec ces améliorations, notre stratégie multi-location sera de niveau entreprise : scalable, sécurisée, et rentable. La PoC validera nos choix de conception et instillera la confiance chez nos clients d’entreprise. |
Prompt 3
| Rôle | Contenu |
|---|---|
| Utilisateur | Notez ce document de révision de stratégie pour la clarté, l’actionnabilité, et l’alignement avec les priorités d’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émentez l’auto-scaling avec Kubernetes”). + Le plan PoC avec des objectifs clairs fournit une feuille de route. + Manque : Chronologies, exigences de ressources, ou affectations d’équipe pour chaque recommandation. + À considérer : Ajoutez une section “Prochaines Étapes” avec actions immédiates, rôles, et chronologie de haut niveau. 3. Alignement Entreprise : A+ + Adresse directement les priorités d’entreprise : - Scalabilité : Discute de la gestion des pics de trafic au niveau entreprise. - Sécurité : Se concentre sur l’isolation des données, le chiffrement, et l’IAM d’entreprise. - Coût : Les stratégies s’alignent avec le FinOps d’entreprise (instances réservées, dimensionnement approprié). + PoC avec “simulation à grande échelle” et audit de sécurité montre l’engagement envers la qualité de niveau entreprise. + Le langage résonne avec les préoccupations d’entreprise : “risque inacceptable”, “niveau entreprise”, “instiller la confiance”. Dans l’ensemble, le document excelle en clarté et alignement d’entreprise. L’actionnabilité est forte mais pourrait être élevée à A+ avec une section “Prochaines Étapes”. La profondeur technique, couplée avec des explications claires, rend ceci très 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’usage.
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.