# Ingénierie des prompts (/fr/docs/verdent-for-vscode/best-practices/prompts)

> Bonnes pratiques pour écrire des prompts efficaces



***

Les prompts efficaces sont le fondement du développement assisté par IA réussi. Des demandes claires et précises accompagnées d'un contexte approprié permettent à Verdent de fournir des résultats précis et pertinents.

### Ce que vous allez apprendre [#ce-que-vous-allez-apprendre]

* Les bonnes pratiques pour écrire des prompts efficaces
* Comment fournir du contexte et éviter les erreurs courantes
* Des techniques avancées comme les @-mentions et la délégation à des sous-agents
* Des exemples de prompts bien structurés
* Des stratégies de raffinement itératif

***

## Ce qui rend un prompt efficace [#ce-qui-rend-un-prompt-efficace]

Les prompts efficaces sont clairs, précis et fournissent le contexte nécessaire pour que Verdent comprenne votre intention et livre des résultats précis.

**Principes clés :**

* **Soyez précis** - Indiquez exactement ce dont vous avez besoin, évitez les demandes vagues
* **Incluez des détails** - Fournissez les spécifications techniques lorsque vous avez des préférences
* **Précisez la portée** - Clarifiez quels fichiers/composants sont concernés
* **Fournissez du contexte** - Aidez Verdent à comprendre votre architecture
* **Indiquez les résultats attendus** - Décrivez à quoi ressemble la réussite
* **Utilisez le langage naturel** - Aucune syntaxe spéciale requise

**Exemples de transformations :**

**Mauvais :**

```
Fix the code
```

**Bon :**

```
Add input validation to the email field in ContactForm.js to reject invalid email formats
```

**Mauvais :**

```
Add authentication
```

**Bon :**

```
Add JWT authentication using the same middleware pattern as auth.js, store tokens in httpOnly cookies
```

***

## Erreurs courantes dans les prompts [#erreurs-courantes-dans-les-prompts]

<Tabs>
  <Tab title="Être trop vague">
    **Exemples de prompts :**

    ```
    Make the app better
    ```

    ```
    Fix the bugs
    ```

    | Problème                                                                        | Solution                                                           |
    | ------------------------------------------------------------------------------- | ------------------------------------------------------------------ |
    | Verdent ne sait pas quelles améliorations vous souhaitez ni quels bugs corriger | Précisez exactement ce qui doit être amélioré ou quel bug corriger |
  </Tab>

  <Tab title="Omettre le contexte">
    **Exemples de prompts :**

    ```
    Add authentication
    ```

    | Problème                                                                     | Solution                                                                                |
    | ---------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- |
    | Verdent pourrait implémenter JWT alors que vous utilisez OAuth, ou l'inverse | Précisez l'approche d'implémentation, les modèles existants et les exigences techniques |
  </Tab>

  <Tab title="Trop de choses à la fois">
    **Exemples de prompts :**

    ```
    Build the entire user management system with authentication, authorization, profiles, settings, and admin dashboard
    ```

    | Problème                                                                                             | Solution                                                                                                    |
    | ---------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- |
    | Les demandes multi-systèmes complexes sont plus difficiles à exécuter correctement en une seule fois | Décomposez en tâches plus petites - commencez par l'authentification, puis l'autorisation, puis les profils |
  </Tab>

  <Tab title="Portée manquante">
    **Exemples de prompts :**

    ```
    Update the validation logic
    ```

    | Problème                                                  | Solution                                                                                                        |
    | --------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- |
    | Il n'est pas clair quels fichiers ou validations modifier | Précisez la portée : « Mettez à jour la validation dans UserController.js pour exiger des mots de passe forts » |
  </Tab>

  <Tab title="Exigences non exprimées">
    **Exemples de prompts :**

    ```
    Expecting Verdent to know your specific business rules or constraints
    ```

    | Problème                                                                   | Solution                                                                 |
    | -------------------------------------------------------------------------- | ------------------------------------------------------------------------ |
    | Verdent implémente des solutions génériques sans vos exigences spécifiques | Énoncez explicitement toutes les contraintes, règles métier et exigences |
  </Tab>

  <Tab title="@-mentions manquantes">
    **Exemples de prompts :**

    ```
    Referencing files without including them in context
    ```

    | Problème                                                      | Solution                                                                     |
    | ------------------------------------------------------------- | ---------------------------------------------------------------------------- |
    | Verdent peut ne pas avoir accès aux fichiers dont vous parlez | Utilisez @nomdefichier.js pour inclure explicitement les fichiers pertinents |
  </Tab>

  <Tab title="Ignorer les erreurs">
    **Exemples de prompts :**

    ```
    Repeatedly asking for the same thing when Verdent encounters errors
    ```

    | Problème                                   | Solution                                                             |
    | ------------------------------------------ | -------------------------------------------------------------------- |
    | La même approche produit les mêmes erreurs | Lisez les messages d'erreur, ajustez le prompt selon ce qui a échoué |
  </Tab>

  <Tab title="Ignorer Plan Mode">
    **Exemples de prompts :**

    ```
    Requesting large refactorings or multi-file changes without using Plan Mode first
    ```

    | Problème                                                                            | Solution                                                                                  |
    | ----------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- |
    | Vous ne voyez pas la portée complète avant que les fichiers ne soient déjà modifiés | Passez en Plan Mode pour les tâches complexes afin de revoir l'approche avant l'exécution |

    <Tip>
      Activez Plan Mode pour les changements complexes afin de revoir l'approche avant l'exécution, cela permet de détecter les malentendus rapidement.
    </Tip>
  </Tab>

  <Tab title="Aucun contrôle de version">
    **Exemples de prompts :**

    ```
    Using Auto-Run or Skip Permission Mode without Git initialized
    ```

    | Problème                                                                | Solution                                                                                                                |
    | ----------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- |
    | Aucun filet de sécurité si Verdent effectue des changements non désirés | Assurez-vous toujours que Git est initialisé et que les changements sont commités avant d'utiliser des modes permissifs |
  </Tab>

  <Tab title="Aucune demande d'entretien">
    **Exemples de prompts :**

    ```
    Providing incomplete requirements and expecting Verdent to guess correctly
    ```

    | Problème                                                                                         | Solution                                                                                                                      |
    | ------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- |
    | Verdent implémente en se basant sur des hypothèses qui peuvent ne pas correspondre à vos besoins | Demandez à Verdent de vous interroger : « Posez-moi des questions de clarification sur les exigences avant de créer le plan » |
  </Tab>
</Tabs>

***

## Exemples de prompts bien structurés [#exemples-de-prompts-bien-structurés]

<Tabs>
  <Tab title="Implémentation de fonctionnalité">
    Créer une nouvelle fonctionnalité avec des exigences et des contraintes claires :

    ```
    Create a POST /api/tasks endpoint that:
    - Accepts task title (required), description (optional), and category_id (required)
    - Validates that the category exists in the database
    - Returns 400 if validation fails with descriptive error messages
    - Saves the task to the database and returns the created task with 201 status
    - Add this to the existing tasks router in routes/tasks.js
    - Create the controller method in controllers/taskController.js
    - Use the existing error handling pattern from other controllers
    ```

    **Ce qui rend ce prompt efficace :**

    * Exigences claires pour les entrées et la validation
    * Emplacements de fichiers précis pour l'implémentation
    * Référence à des modèles existants pour maintenir la cohérence
    * Codes de statut HTTP attendus et gestion des erreurs
  </Tab>

  <Tab title="Correction de bug">
    Décrire les problèmes avec le contexte et les solutions proposées :

    ```
    Fix the race condition in payment processing at checkout. When multiple users submit payments simultaneously, some transactions fail with "duplicate order ID" errors. The issue appears to be in PaymentController.js around line 45 where we generate order IDs. Implement proper locking or use UUID generation to ensure unique IDs even under concurrent load.
    ```

    **Ce qui rend ce prompt efficace :**

    * Description claire du problème avec les symptômes
    * Emplacement précis du problème (fichier et numéro de ligne)
    * Contexte sur le moment où cela se produit (utilisateurs simultanés)
    * Approches de solution suggérées
  </Tab>

  <Tab title="Refactorisation">
    Changer l'implémentation en préservant le comportement :

    ```
    Refactor the authentication middleware in middleware/auth.js to use JWT tokens instead of session cookies. Keep the same authorization logic, but:
    - Replace session validation with JWT verification
    - Store tokens in httpOnly cookies
    - Maintain the existing user object structure that routes expect
    - Update only the authentication mechanism, don't change authorization rules
    - Ensure all existing routes continue to work without modification
    ```

    **Ce qui rend ce prompt efficace :**

    * Objectif clair (JWT au lieu des sessions)
    * Fichier précis à refactoriser
    * Contraintes explicites (ce qui ne doit PAS changer)
    * Exigence de compatibilité ascendante
  </Tab>

  <Tab title="Tests">
    Écrire des tests avec une couverture complète :

    ```
    Write comprehensive unit tests for the UserService class in services/UserService.js. Cover:
    - User creation with valid and invalid data
    - Email validation edge cases (empty, malformed, duplicate)
    - Password hashing verification
    - User lookup by ID and email
    - Error handling for database failures
    Use Jest and follow the testing patterns in existing service tests
    ```

    **Ce qui rend ce prompt efficace :**

    * Classe/fichier précis à tester
    * Liste complète des scénarios à couvrir
    * Framework de test précisé
    * Référence à des modèles de tests existants
  </Tab>

  <Tab title="Création de composant">
    Construire des composants d'interface avec des spécifications détaillées :

    ```
    Create a reusable SearchBar component for the product catalog with:
    - Text input with real-time debounced search (300ms delay)
    - Category dropdown filter (fetch options from /api/categories)
    - Price range slider (min $0, max $1000)
    - Clear filters button
    - Use Material-UI components to match existing design
    - Emit search parameters via onChange callback to parent
    - Include PropTypes for all props
    ```

    **Ce qui rend ce prompt efficace :**

    * Liste complète des fonctionnalités avec détails précis
    * Spécifications techniques (debounce de 300 ms, plage de prix)
    * Bibliothèque d'interface précisée (Material-UI)
    * Approche d'intégration (callback vers le parent)
  </Tab>
</Tabs>

***

## Techniques avancées de prompting [#techniques-avancées-de-prompting]

<Tabs>
  <Tab title="@-mentions">
    Référencer des fichiers, composants ou sous-agents spécifiques :

    ```
    @auth.js @UserController.js Refactor authentication to use the same validation pattern
    ```

    **Avantages :**

    * Garantit que Verdent dispose du contexte exact en incluant explicitement des fichiers spécifiques
    * Évite l'ambiguïté dans les grandes bases de code avec des noms de fichiers similaires
    * Garantit que tout le code pertinent est visible simultanément pour une refactorisation précise et une correspondance de motifs
    * Essentiel lorsqu'on référence des modèles d'implémentation d'un fichier pour les appliquer dans un autre
  </Tab>

  <Tab title="Plan Mode">
    Passez en Plan Mode avant l'exécution pour les changements importants :

    ```
    Switch to Plan Mode
    Refactor the entire API layer to use TypeScript with strict type checking
    ```

    **Avantages :**

    * Passez en revue l'approche complète de Verdent avant qu'aucun fichier ne soit modifié
    * Empêche des erreurs coûteuses dans les refactorisations importantes ou les changements architecturaux
    * Itérez sur le plan, ajoutez des contraintes ou redirigez complètement avant que l'exécution ne commence
    * Demandez à Verdent de vous interroger avec des questions de clarification pour rassembler toutes les exigences en amont
  </Tab>

  <Tab title="Délégation à des sous-agents">
    Déléguer des tâches spécialisées à des sous-agents intégrés ou personnalisés :

    ```
    @Code-reviewer Review the security vulnerabilities in authentication flow
    @Explorer Find all files that import the deprecated API client
    @Verifier Validate the authentication logic in the middleware
    ```

    **Avantages :**

    * Exploitez des agents spécialisés optimisés pour des tâches spécifiques (exploration, vérification, revue de code)
    * Expertise ciblée et résultats plus rapides qu'un traitement à usage général
    * Exécutez plusieurs analyses en parallèle pour réduire considérablement le temps d'exécution total
    * Créez des sous-agents personnalisés avec des connaissances propres à un domaine pour les exigences spécifiques de votre projet

    **Sous-agents intégrés par défaut :**

    * `@Verifier` - Vérifications rapides du code et validation
    * `@Explorer` - Exploration rapide de la base de code et recherche de fichiers
    * `@Code-reviewer` - Évaluation de la qualité du code

    <Tip>
      Utilisez @Explorer pour les questions sur la base de code et @Code-reviewer pour l'analyse de sécurité, une délégation ciblée est plus rapide que le routage via l'agent principal.
    </Tip>
  </Tab>

  <Tab title="Think Hard Mode">
    Activez le raisonnement étendu pour les défis complexes :

    ```
    Think: Design the optimal database schema for a multi-tenant SaaS application
    ```

    **Avantages :**

    * Active un raisonnement étendu pour une analyse plus approfondie des problèmes complexes sous plusieurs angles
    * Évalue les approches alternatives et les cas limites de manière plus approfondie
    * Produit des solutions robustes lorsque la justesse est primordiale
    * Réponses plus lentes et consommation de crédits plus élevée, mais évite un retravail coûteux dû à des solutions hâtives et sous-optimales

    <Tip>
      Think Hard Mode excelle dans les décisions d'architecture, le débogage complexe et les problèmes algorithmiques nécessitant une analyse approfondie.
    </Tip>
  </Tab>

  <Tab title="Raffinement itératif">
    Vous appuyer sur les réponses précédentes avec un raffinement progressif :

    ```
    Initial: "Create a dashboard component"
    Follow-up: "Add real-time data updates using WebSockets"
    Follow-up: "Now add filtering and sorting capabilities"
    ```

    **Avantages :**

    * Permet un développement incrémental avec des tests à chaque étape avant d'ajouter de la complexité
    * Réduit les risques en validant que chaque couche fonctionne correctement avant de construire sur celle-ci
    * Corrigez immédiatement le cap si les itérations produisent des résultats inattendus
    * Facilite l'identification du changement précis ayant introduit un bug, car chaque itération est petite et contenue

    <Tip>
      Le raffinement itératif réduit les risques, commencez avec une portée réduite, vérifiez les résultats, puis élargissez progressivement.
    </Tip>
  </Tab>

  <Tab title="Approche par contraintes">
    Préciser ce qui ne doit PAS être changé en parallèle de ce qui doit changer :

    ```
    Add caching to the API endpoints, but:
    - Don't modify the authentication middleware
    - Keep the existing error handling unchanged
    - Maintain backward compatibility with mobile clients
    ```

    **Avantages :**

    * Définit explicitement des limites pour éviter de modifier des systèmes critiques (authentification, paiements)
    * Protège les systèmes stables qui doivent rester inchangés en raison d'exigences de conformité ou de risque
    * Évite des cycles coûteux consistant à implémenter des changements, découvrir des fonctionnalités cassées, puis retravailler les solutions
    * Maintient la compatibilité ascendante et protège le code éprouvé d'une refactorisation inutile
  </Tab>

  <Tab title="Modèles de référence">
    Pointer vers du code existant comme exemples d'implémentation :

    ```
    Implement the new ProductService following the same pattern as UserService.js, including error handling, validation, and database transaction management
    ```

    **Avantages :**

    * Garantit que les nouvelles implémentations restent cohérentes avec les conventions établies
    * Rend la base de code plus maintenable et plus prévisible
    * Réduit considérablement le besoin d'explications - pointez vers des exemples plutôt que de décrire les approches en détail
    * Exploite des modèles éprouvés et testés plutôt que de réinventer des solutions
    * Réduit les bugs et garantit une intégration fluide avec les systèmes existants
  </Tab>

  <Tab title="Planification via todos.md">
    Créer un fichier todos.md pour suivre les tâches complexes et multi-étapes :

    ```
    Create a todos.md file with these tasks:
    1. Refactor authentication to use JWT tokens
    2. Update all controllers to use new auth middleware
    3. Add tests for authentication flow
    4. Update API documentation
    ```

    **Avantages :**

    * Crée une feuille de route claire et écrite qui peut être revue, affinée et partagée avec les coéquipiers
    * S'ajuste facilement à mesure que les exigences évoluent tout au long du projet
    * Persiste entre les sessions pour que vous puissiez interrompre le travail, le reprendre plus tard et comprendre immédiatement où vous en étiez
    * Sert d'artefact de projet documentant ce qui a été planifié, achevé et ce qui reste, pour la maintenance future et l'intégration de nouveaux membres
  </Tab>

  <Tab title="Effacer le contexte">
    Démarrer de nouvelles sessions entre différentes tâches pour un contexte frais :

    ```
    After completing todo #1: "Start a new session"
    Then: "Let's work on todo #2 from todos.md"
    ```

    **Avantages :**

    * Empêche la contamination du contexte où les détails d'une tâche précédente influencent de manière inappropriée le travail en cours
    * Garantit une concentration sur la tâche en cours uniquement, sans le poids des tâches précédentes
    * Réduit l'utilisation de tokens en ne chargeant pas d'historique de conversation inutile
    * Rend les réponses plus rapides et plus économes en crédits
    * Crée des points de contrôle naturels pour les tests et la validation des changements, maintenant un historique Git propre et une isolation plus facile des problèmes
  </Tab>

  <Tab title="Serveurs MCP">
    Utilisez des serveurs MCP (Model Context Protocol) pour injecter du contexte spécialisé :

    * Documentation spécifique au projet
    * Spécifications API (OpenAPI, schémas GraphQL)
    * Connaissances spécifiques à un framework

    **Avantages :**

    * Améliore la compréhension par Verdent des frameworks personnalisés, outils internes et domaines spécialisés absents de ses données d'entraînement
    * Élimine le besoin d'expliquer de manière répétée des systèmes personnalisés en injectant directement les spécifications API propres à l'organisation et la documentation
    * Permet une utilisation correcte des APIs internes et des systèmes propriétaires qu'il serait impossible de transmettre par les prompts seuls
  </Tab>
</Tabs>

***

## Inclure du contexte dans les prompts [#inclure-du-contexte-dans-les-prompts]

<Tabs>
  <Tab title="@-mentions pour les fichiers">
    Inclure explicitement les fichiers pertinents dans le contexte :

    ```
    @models/User.js @controllers/UserController.js Add password reset functionality
    ```

    **Quand l'utiliser :**

    * Lors du travail avec des fichiers étroitement liés (modèle et contrôleur, service et tests)
    * Référencer des modèles d'implémentation d'un fichier pour les appliquer dans un autre
    * Coordonner des changements sur plusieurs fichiers liés
    * Dans les grandes bases de code avec des noms de fichiers similaires où la détection automatique pourrait manquer du contexte
    * Utilisez toujours cette technique lorsque vous demandez à Verdent de « suivre le même modèle que... » pour garantir qu'il dispose du code exact
  </Tab>

  <Tab title="Architecture du projet">
    Inclure le contexte de haut niveau sur votre stack :

    ```
    This is a MERN stack application (MongoDB, Express, React, Node.js) with JWT authentication. Add role-based access control following our existing middleware pattern.
    ```

    **Quand l'utiliser :**

    * Lors de l'implémentation de fonctionnalités devant s'intégrer à votre stack technique existant
    * Premier travail dans une base de code ou fonctionnalités s'étendant sur plusieurs couches (frontend à base de données)
    * Lorsque votre stack a des choix marqués (GraphQL vs REST, Redux vs Context API) affectant les choix d'implémentation
    * Lorsque vous avez besoin que Verdent choisisse l'approche adaptée à votre système plutôt qu'une solution générique
  </Tab>

  <Tab title="Modèles existants">
    Pointer vers du code démontrant vos conventions :

    ```
    Follow the same error handling pattern used in ProductController.js - return consistent error objects with status codes and descriptive messages
    ```

    **Quand l'utiliser :**

    * Lorsque vous voulez que le nouveau code reste cohérent avec les conventions établies (gestion des erreurs, validation, journalisation, tests)
    * Implémentation de fonctionnalités similaires dans une nouvelle zone de la base de code
    * Intégration dans des parties peu familières de la base de code où vous souhaitez apprendre et reproduire les modèles existants
    * Lorsque vous voulez éviter de décrire les modèles en détail et avez besoin que Verdent capture des nuances difficiles à formuler
  </Tab>

  <Tab title="Contraintes techniques">
    Énoncer les limitations ou exigences :

    ```
    We're using TypeScript with strict mode enabled, React 18 with hooks only (no class components), and Material-UI v5 for styling
    ```

    **Quand l'utiliser :**

    * Lorsque votre projet a des exigences technologiques spécifiques (mode strict TypeScript, hooks React uniquement, aucune dépendance externe)
    * Travail avec des contraintes héritées (support IE11, compatibilité Node.js 14)
    * Lorsque des exigences de conformité dictent les choix (accessibilité WCAG, gestion des données RGPD)
    * Utilisation de versions spécifiques de bibliothèques avec des changements majeurs entre versions
    * Lorsque vous devez empêcher Verdent de proposer des solutions violant les limites techniques de votre projet
  </Tab>

  <Tab title="Logique métier">
    Expliquer les règles spécifiques au domaine :

    ```
    Users can only view tasks assigned to them or their team. Managers can view all tasks in their department. Admins can view everything.
    ```

    **Quand l'utiliser :**

    * Lors de l'implémentation de fonctionnalités avec des règles spécifiques au domaine que Verdent ne peut pas déduire du code seul
    * Logique d'autorisation (qui peut accéder à quoi), flux métier (processus d'approbation, machines à états)
    * Règles de validation (politiques de mot de passe, contraintes de données), contraintes de domaine (limites d'inventaire, règles de tarification)
    * Construction de modèles de données où les relations entre entités et la cardinalité doivent être expliquées
    * Implémentation de calculs (règles de remise, calcul de taxes, structures de commission)
    * Lorsque vous avez besoin que Verdent applique correctement les règles métier de votre organisation, pas seulement du code fonctionnel
  </Tab>

  <Tab title="Contexte d'erreur">
    Partager les messages d'erreur ou logs lors du débogage :

    ```
    Getting "TypeError: Cannot read property 'id' of undefined" at UserController.js:42 when trying to update user profiles. The req.user object exists but doesn't have an id property after the recent auth middleware changes.
    ```

    **Quand l'utiliser :**

    * Incluez toujours les messages d'erreur complets, les traces de pile et les logs lors de la correction de bugs
    * Erreurs d'exécution (exceptions, plantages), échecs de compilation (erreurs de compilation, violations de linting)
    * Échecs de tests (erreurs d'assertion, problèmes de délai), comportement inattendu (mauvaise sortie, données manquantes)
    * Lorsque vous disposez de messages d'erreur exacts avec numéros de ligne et trace de pile complète montrant la chaîne d'appels
    * Lorsque vous pouvez fournir un contexte sur le moment où cela se produit (toujours, par intermittence, conditions spécifiques)
    * Lorsque vous voulez améliorer considérablement la capacité de Verdent à identifier les causes profondes plutôt que de deviner
  </Tab>

  <Tab title="Chargement automatique">
    Verdent charge automatiquement les fichiers pertinents en fonction de votre demande :

    * Fichiers mentionnés par leur nom dans les prompts
    * Fichiers liés dans le même répertoire
    * Fichiers de projet fréquemment consultés

    **Quand s'appuyer sur cela :**

    * Pour les références standard de fichiers où les relations sont évidentes
    * Mentionner des composants par leur nom lorsque Verdent doit charger ce fichier spécifique
    * Travail avec des fichiers du même répertoire fonctionnant habituellement ensemble
    * Accès aux fichiers de projet fréquemment utilisés (package.json, fichiers de configuration)
    * Fonctionne bien pour les scénarios simples dans des bases de code bien organisées
    * Pour les refactorisations multi-fichiers complexes, les parties distantes de la base de code ou les noms de fichiers ambigus, utilisez plutôt des @-mentions explicites
  </Tab>

  <Tab title="Règles de projet/utilisateur">
    Configurer un contexte persistant via des fichiers de règles (Paramètres → Règles) :

    **Règles utilisateur (VERDENT.md) :**
    Préférences globales appliquées à tous les projets

    **Règles de projet (AGENTS.md) :**
    Standards spécifiques au projet - modèles architecturaux, standards de codage

    **Règles de plan (plan\_rules.md) :**
    Personnaliser le format et le contenu du plan en Plan Mode

    **Quand l'utiliser :**

    * Lorsque vous fournissez de manière répétée le même contexte au fil des sessions
    * Règles utilisateur pour les préférences personnelles (style de code, bibliothèques préférées, modèles que vous favorisez)
    * Règles de projet pour les standards d'équipe (décisions architecturales, conventions de nommage, exigences de tests)
    * Précieux pour l'intégration de nouveaux membres de l'équipe (codifie les connaissances tribales)
    * Maintien de la cohérence au sein de grandes équipes et réduction de la verbosité des prompts
    * Investissez dans des fichiers de règles lorsque votre projet a suffisamment mûri pour avoir des modèles établis qui méritent d'être documentés
  </Tab>

  <Tab title="Images">
    Inclure des captures d'écran, maquettes ou diagrammes :

    ```
    @screenshot.png Implement this UI design with React components
    ```

    **Quand l'utiliser :**

    * Lorsque l'information visuelle communique les exigences plus efficacement que le texte
    * Implémentation UI/UX (maquettes de conception, wireframes, parcours utilisateur)
    * Débogage de problèmes visuels (capture d'écran d'une mise en page cassée, problèmes de rendu)
    * Compréhension d'architectures complexes (diagrammes de systèmes, schémas de bases de données, organigrammes)
    * Essentiel pour la conception responsive, l'analyse d'accessibilité et la reproduction d'erreurs
    * Traduction de conceptions provenant d'outils comme Figma ou Sketch en code
    * Une seule capture d'écran bien réalisée transmet souvent des détails qui prendraient des paragraphes à décrire
  </Tab>

  <Tab title="Liens de sites web">
    Référencer une documentation externe ou des exemples :

    ```
    Ultrathink: Read this API documentation at https://api-docs.example.com/v1/endpoints and implement the authentication flow
    ```

    **Quand l'utiliser :**

    * Lors de l'implémentation d'intégrations avec des APIs ou bibliothèques externes disposant d'une documentation officielle en ligne
    * Particulièrement précieux lorsque la bibliothèque a des options de configuration ou des flux d'authentification complexes
    * Utilisez le préfixe « Ultrathink : » pour demander à Verdent de récupérer et analyser le contenu web avant de générer du code
    * Essentiel pour les APIs évoluant rapidement, où la documentation est plus à jour que les données d'entraînement
    * Lors du suivi de modèles spécifiques à un framework (App Router Next.js, Vue Composition API)
    * Garantit que les implémentations correspondent aux versions actuelles de API et suivent les recommandations officielles
  </Tab>
</Tabs>

***

## Stratégies de raffinement itératif [#stratégies-de-raffinement-itératif]

<Tabs>
  <Tab title="Du général au spécifique">
    **Prompt initial :**

    ```
    Add authentication to the API
    ```

    La réponse de Verdent pourrait être générique. Affinez :

    ```
    Use JWT tokens stored in httpOnly cookies, implement refresh token rotation, and follow the authentication pattern from our existing UserController
    ```

    **Quand l'utiliser :** Commencer par une demande générale, puis ajouter des détails selon la réponse initiale
  </Tab>

  <Tab title="Revoir et corriger">
    Si l'implémentation de Verdent ne correspond pas aux attentes :

    ```
    The validation logic is good, but use Joi schema validation instead of manual checks. Match the validation pattern in ProductController.js
    ```

    **Quand l'utiliser :** Après avoir revu le résultat et identifié des améliorations spécifiques
  </Tab>

  <Tab title="Prompts de suivi">
    Construire de manière incrémentale :

    ```
    Initial: "Create a UserProfile component"
    Follow-up: "Add an avatar upload feature with image preview"
    Follow-up: "Add validation - max 5MB, only jpg/png formats"
    Follow-up: "Show upload progress with a progress bar"
    ```

    **Quand l'utiliser :** Construire des fonctionnalités progressivement dans la même session
  </Tab>

  <Tab title="Demander des explications">
    Si l'implémentation semble inattendue :

    ```
    Why did you use Redux instead of Context API? Can you explain the trade-offs for this use case?
    ```

    Puis affinez selon la compréhension :

    ```
    Actually, use Context API for consistency with the rest of our application
    ```

    **Quand l'utiliser :** Comprendre le raisonnement avant de demander des changements
  </Tab>

  <Tab title="Raffinement en Plan Mode">
    Pour les changements complexes :

    ```
    Switch to Plan Mode
    Show me how you would refactor the authentication system to support OAuth providers
    ```

    Revoyez le plan, posez des questions, itérez sur l'approche avant l'exécution.

    **Quand l'utiliser :** Changements architecturaux majeurs nécessitant une revue
  </Tab>

  <Tab title="Fournir des exemples">
    Si le style de Verdent ne correspond pas au vôtre :

    ```
    The component structure is close, but use this pattern instead:
    [paste example of your preferred structure]
    Apply this same pattern to the remaining components
    ```

    **Quand l'utiliser :** Établir ou renforcer les préférences de style de code
  </Tab>

  <Tab title="Clarifier les contraintes">
    Si le résultat viole des contraintes non énoncées :

    ```
    Good approach, but don't modify the database schema - work within the existing User table structure
    ```

    **Quand l'utiliser :** Ajouter des contraintes découvertes après avoir vu l'implémentation initiale
  </Tab>

  <Tab title="Amélioration progressive">
    Commencer par les fonctionnalités essentielles, ajouter des fonctionnalités de manière itérative :

    ```
    Step 1: "Create basic CRUD endpoints for tasks"
    Step 2: "Add pagination to the GET endpoint"
    Step 3: "Add filtering by status and priority"
    Step 4: "Add full-text search across title and description"
    ```

    **Quand l'utiliser :** Construire des fonctionnalités complexes de manière incrémentale avec des tests à chaque étape
  </Tab>
</Tabs>

***

## FAQ [#faq]

<Accordion title="À quel point mes prompts doivent-ils être précis ?">
  Soyez suffisamment précis pour éliminer l'ambiguïté, mais n'expliquez pas de manière excessive des détails évidents. Incluez : les chemins de fichiers exacts, l'approche d'implémentation, les résultats attendus et les contraintes. Mauvais : « Corrige le code » - trop vague. Bon : « Ajoute une validation d'entrée sur le champ email dans `ContactForm.js` pour rejeter les formats d'email invalides » - portée et objectif clairs. En cas de doute, privilégiez davantage de précision.
</Accordion>

<Accordion title="Quelle est la différence entre les @-mentions et le chargement automatique de fichiers ?">
  Verdent charge automatiquement les fichiers mentionnés par leur nom dans les prompts ainsi que les fichiers liés dans le même répertoire. `@-mentions` (`@filename.js`) garantissent explicitement qu'un fichier est dans le contexte, ce qui est essentiel lors du travail avec des fichiers étroitement liés, du référencement de modèles d'un fichier pour les appliquer dans un autre, ou lorsque la détection automatique pourrait manquer du contexte dans les grandes bases de code. Utilisez toujours `@-mentions` lorsque vous demandez à Verdent de « suivre le même modèle que... » pour garantir une référence exacte au code.
</Accordion>

<Accordion title="Quand devrais-je utiliser Plan Mode plutôt que le mode normal ?">
  Utilisez Plan Mode pour : les refactorisations importantes ou les changements architecturaux, les modifications multi-fichiers où vous voulez revoir la portée avant l'exécution, les tâches complexes où vous n'êtes pas certain des exigences, ou lorsque vous voulez que Verdent vous interroge avec des questions de clarification avant l'implémentation. Évitez Plan Mode pour : les tâches simples et bien définies, les corrections de bugs rapides ou les opérations de routine. Plan Mode ajoute une charge supplémentaire mais évite des erreurs coûteuses sur les travaux complexes.
</Accordion>

<Accordion title="Que faire si Verdent ne comprend pas ou ne suit pas correctement mon prompt ?">
  Utilisez le raffinement itératif : revoyez le résultat, identifiez ce qui est incorrect, puis fournissez des corrections dans un prompt de suivi. Exemple : « La logique de validation est bonne, mais utilise la validation de schéma Joi au lieu de vérifications manuelles. Suis le modèle de validation dans `ProductController.js`. » Vous pouvez aussi demander des explications : « Pourquoi as-tu utilisé Redux au lieu de Context API ? » puis affiner selon la compréhension. Ne répétez pas le même prompt - ajustez selon ce qui a échoué.
</Accordion>

<Accordion title="Dois-je répéter le contexte du projet dans chaque prompt au cours d'une session ?">
  Non - Verdent maintient le contexte de la conversation au sein d'une session, vous n'avez donc pas besoin de répéter les détails d'architecture ou les conventions déjà discutés. Cependant, pour les contraintes critiques ou lorsque les sessions deviennent longues (`100+` messages), réaffirmez le contexte important. Meilleure approche : utilisez des règles de projet (`AGENTS.md`) pour documenter un contexte persistant tel que la stack technique, les standards de codage et les modèles - vous n'aurez alors jamais besoin de les répéter.
</Accordion>

<Check>
  Des prompts bien structurés avec une intention claire, un contexte pertinent et des contraintes précises produisent systématiquement de meilleurs résultats.
</Check>

***

## Voir aussi [#voir-aussi]

<CardGroup cols="3">
  <Card title="Gestion du contexte" href="/docs/verdent-for-vscode/best-practices/context" icon="layer-group">
    Gérer les fenêtres de contexte et les stratégies d'optimisation
  </Card>

  <Card title="Modes d'exécution" href="/docs/verdent-for-vscode/execution-modes/overview" icon="toggle-on">
    Comprendre les modes d'exécution pour différents scénarios
  </Card>

  <Card title="Gestion des erreurs" href="/docs/verdent-for-vscode/error-handling/recovery" icon="triangle-exclamation">
    Gérer les erreurs et résoudre les problèmes
  </Card>
</CardGroup>
