Workflow Agent Double Mode Plan vs Act dans Cursor

L'un des plus grands défis avec les agents de codage IA est de les empêcher d'effectuer des modifications non autorisées. Le workflow dual-mode Plan vs Act résout cela en exigeant que l'agent propose des changements en "mode Plan" avant de les exécuter en "mode Act". Ce guide vous montre comment implémenter ce puissant pattern de sécurité dans Cursor.

Qu'est-ce que Plan vs Act ?

Mode Plan (Lecture seule)

En mode Plan, l'agent :

• Lit et analyse le code
• Propose des changements dans un format structuré
• Ne peut modifier aucun fichier
• Présente un plan détaillé pour révision par l'utilisateur

Mode Act (Lecture-Écriture)

En mode Act, l'agent :

• Exécute uniquement les changements approuvés
• A un accès complet en lecture-écriture
• Suit le plan exact fourni
• Reporte ce qui a été fait

Pourquoi utiliser ce pattern ?

Sans Plan/Act	Avec Plan/Act
L'IA modifie les fichiers de manière inattendue	Tous les changements nécessitent une approbation
Difficile de réviser ce qui a changé	Un plan clair est présenté en premier
Les rollbacks sont difficiles	Les changements sont traçables et réversibles
Dérive du contexte sur de longues sessions	Exécution concentrée par tâche

Méthode d'implémentation 1 : Règles Cursor

Créer .cursor/rules/plan-act-workflow.mdc :

---
description: 'Workflow dual-mode Plan vs Act'
globs: ['**/*']
alwaysApply: true
---

# Workflow Plan vs Act

## RÈGLE CRITIQUE
Vous NE DEVEZ PAS modifier de fichiers sans approbation explicite de l'utilisateur.

## Mode Plan (Par défaut)
Lorsqu'une tâche est donnée :
1. LIRE et analyser les fichiers pertinents
2. CRÉER un plan détaillé avec des changements spécifiques
3. PRÉSENTER le plan dans ce format :

### Plan : [Nom de la tâche]

#### Fichiers à modifier
- `file/path/one.ts` - Quoi changer
- `file/path/two.ts` - Quoi changer

#### Résumé des changements
1. Description du changement 1
2. Description du changement 2

#### Nouveaux fichiers (s'il y en a)
- `new/file/path.ts` - Objectif

#### Plan de test
- Comment vérifier que les changements fonctionnent

4. ATTENDRE que l'utilisateur tape "PROCEED" ou "ACT"

## Mode Act (Après approbation)
Seulement après que l'utilisateur dise "PROCEED" :
1. Implémenter les changements du plan
2. Ne faire QUE les changements approuvés
3. Reporter l'achèvement avec la liste des fichiers
4. Suggérer des étapes de test

## JAMAIS
- Sauter la phase de planification
- Ajouter des changements non planifiés
- Modifier des fichiers pendant le mode Plan
- Demander l'approbation plus d'une fois par plan

Méthode d'implémentation 2 : Mode personnalisé

Créer un mode personnalisé dans les paramètres Cursor :

1. Ouvrir les paramètres Cursor (Cmd/Ctrl + ,)
2. Naviguer vers "Modes" ou "AI Features"
3. Cliquer sur "Add Custom Mode"
4. Configurer :

{
  "name": "Planner",
  "description": "Mode planification - analyse en lecture seule",
  "systemPrompt": "Vous êtes en mode PLANIFICATION. Vous pouvez LIRE des fichiers mais NE JAMAIS les modifier. Analysez la base de code, comprenez les exigences, et présentez un plan détaillé. Attendez l'approbation de l'utilisateur avant tout changement.",
  "tools": ["read", "grep", "search"],
  "fileWrite": false
}

{
  "name": "Executor",
  "description": "Mode exécution - implémenter les changements approuvés",
  "systemPrompt": "Vous êtes en mode EXÉCUTION. Implémentez UNIQUEMENT les changements qui ont été approuvés dans le plan. Ne déviez pas du périmètre approuvé. Reportez chaque changement au fur et à mesure.",
  "tools": ["read", "write", "edit"],
  "fileWrite": true
}

Méthode d'implémentation 3 : Workflow basé sur le chat

Étape 1 : Commencer en mode Plan

[PLAN MODE] J'ai besoin d'ajouter l'authentification utilisateur à cette app.
Veuillez analyser la base de code et créer un plan.
Ne faites AUCUN changement pour l'instant.

Étape 2 : L'agent présente le plan

## Plan : Ajouter l'authentification utilisateur

### Fichiers à modifier
1. `src/app.ts` - Ajouter le middleware d'auth
2. `src/routes/users.ts` - Ajouter les endpoints login/register
3. `src/models/user.ts` - Ajouter le hachage de mot de passe

### Nouveaux fichiers
1. `src/middleware/auth.ts` - Vérification JWT
2. `src/services/auth.ts` - Logique d'auth
3. `tests/auth.test.ts` - Tests unitaires

### Détails d'implémentation
- Utiliser bcrypt pour le hachage de mot de passe
- Tokens JWT avec expiration 15min
- Rotation des refresh tokens

### Tests
- Tester login avec identifiants valides/invalides
- Tester refresh de token
- Tester routes protégées

Étape 3 : Réviser et approuver

Vous révisez le plan et soit :

• Tapez PROCEED pour approuver
• Demandez des modifications
• Rejetez et recommencez

Étape 4 : Exécuter

[ACT MODE] PROCEED avec le plan d'authentification.
Implémentez exactement ce qui a été approuvé.

Étape 5 : Vérification

Après exécution :

Vérifiez que tous les changements ont été faits correctement :
1. Vérifier que le middleware d'auth est appliqué
2. Tester l'endpoint de login
3. Exécuter les tests d'auth

Avancé : Parsing automatisé du plan

Pour les projets complexes, utilisez un format de plan structuré :

## Plan ID : AUTH-001
## Statut : EN_ATTENTE_APPROBATION
## Priorité : HAUTE
## Temps estimé : 30 minutes

### Portée
- Ajouter l'authentification basée sur JWT
- Implémenter login/logout/register
- Ajouter le flux de réinitialisation de mot de passe

### Changements

#### Fichier : src/middleware/auth.ts (NOUVEAU)
```typescript
import jwt from 'jsonwebtoken';

export const verifyToken = (req, res, next) => {
  // Implémentation
};

Fichier : src/routes/auth.ts (NOUVEAU)

// Endpoints login, register, logout

Fichier : src/app.ts (MODIFIER)

• Ligne 15 : Ajouter app.use('/auth', authRoutes)

Rollback

• Supprimer : src/middleware/auth.ts
• Supprimer : src/routes/auth.ts
• Rétablir : src/app.ts ligne 15

Tests

• Login avec identifiants valides
• Login avec identifiants invalides
• Accéder à une route protégée sans token
• Accéder à une route protégée avec token valide

## Intégration avec le contrôle de version

### Point de contrôle pré-exécution

Avant d'exécuter un plan :

```bash
# Créer une branche de point de contrôle
git checkout -b plan/auth-implementation

# Commettre l'état actuel
git add -A && git commit -m "checkpoint: avant implémentation auth"

Vérification post-exécution

# Réviser les changements
git diff

# Si quelque chose ne va pas, revenir en arrière
git checkout -- .

# Ou revenir au point de contrôle
git reset --hard HEAD~1

Workflow d'équipe

Pour les revues de code

1. Le développeur crée un plan dans Cursor
2. Le développeur colle le plan dans la description de la PR
3. Le reviewer approuve le plan avant exécution
4. Le développeur exécute avec le workflow Plan vs Act
5. Le reviewer vérifie que l'exécution correspond au plan

Template de PR

## Plan
[Coller le plan généré par l'IA ici]

## Exécution
- [ ] Tous les changements planifiés implémentés
- [ ] Aucune modification non planifiée
- [ ] Les tests passent
- [ ] Le plan correspond à l'exécution

## Vérification
[Décrire les tests effectués]

Pièges courants

Piège	Solution
L'agent saute la planification	Imposer avec des règles et des restrictions de mode
Les plans sont trop vagues	Exiger des chemins de fichiers et numéros de ligne spécifiques
Fatigue d'approbation utilisateur	Regrouper les changements liés en plans uniques
L'exécution dévie du plan	Comparer le diff avec le plan après exécution
Trop d'aller-retour	Autoriser les écarts mineurs, signaler les majeurs

Checklist de démarrage rapide

• Créer .cursor/rules/plan-act-workflow.mdc
• Tester avec une petite tâche sûre
• Vérifier que l'agent respecte le mode lecture seule
• Pratiquer l'approbation et le rejet de plans
• Configurer des checkpoints git avant exécution
• Documenter le workflow pour votre équipe

Ressources connexes

• Cursor Agent Mode Masterclass
• Utiliser efficacement les règles Cursor
• Guide des hooks d'auto-révision Cursor