Implémentation des hooks d'auto-révision dans Cursor pour un codage IA plus sûr

Les assistants de codage IA sont puissants, mais ils peuvent générer du code dangereux, exécuter des commandes dangereuses ou introduire des bugs subtils. Les hooks d'auto-révision créent un filet de sécurité en faisant auditer le travail de l'IA à des points critiques. Ce guide vous montre comment implémenter un système de hooks complet dans Cursor.

Que sont les hooks d'auto-révision ?

Les hooks d'auto-révision sont des points de contrôle automatisés où l'IA révise sa propre sortie avant de continuer. Ils agissent comme :

• Gardes de sécurité : Bloquent les commandes dangereuses (rm -rf /, curl | sh)
• Relecteurs de code : Vérifient les erreurs de logique et les anti-patterns
• Filets de sécurité : Empêchent les force-pushes et les opérations destructrices
• Quality gates : Assurent la cohérence avec les standards du projet

Les quatre événements de hook

Hook 1 : Démarrage de session - Injection de doctrine

Lorsqu'une nouvelle session commence, injectez les principes de sécurité.

Créez .cursor/hooks/doctrine.md :

# Doctrine Cursor - La sécurité d'abord

## Principes fondamentaux
1. **Ne jamais exécuter de commandes destructrices sans confirmation**
2. **Toujours vérifier les chemins de fichiers avant la suppression**
3. **Réviser tout le code avant d'appliquer les changements**
4. **Préférer les valeurs par défaut sûres à la commodité**

## Patterns dangereux à signaler
- `rm -rf` avec des chemins absolus
- `curl ... | sh` ou `wget ... | bash`
- `git push --force` ou `git push -f`
- Commandes de suppression de base de données
- Escalade de privilèges (`sudo`, `chmod 777`)
- SQL brut sans paramétrage

## Checklist de révision
Avant de compléter une tâche :
- [ ] Pas de commandes destructrices dans les exécutions shell
- [ ] Toutes les opérations de fichiers utilisent des chemins vérifiés
- [ ] Pas de secrets ou d'identifiants codés en dur
- [ ] La gestion des erreurs est présente
- [ ] Les changements sont réversibles

Hook 2 : Auto-révision post-édition

Après avoir édité des fichiers, révisez automatiquement le diff.

Créez .cursor/hooks/post-edit-review.md :

# Auto-révision post-édition

Vous venez d'apporter des modifications. Avant de continuer, révisez :

## Vérification de sécurité
- [ ] Pas de secrets, de clés API ou de mots de passe ajoutés
- [ ] Pas de vulnérabilités d'injection SQL
- [ ] Pas de vulnérabilités XSS dans le code web
- [ ] La validation des entrées est présente

## Vérification de logique
- [ ] Les cas limites sont gérés
- [ ] Les chemins d'erreur sont couverts
- [ ] Pas de boucles infinies ou de récursion sans cas de base
- [ ] Le nettoyage des ressources (fichiers, connexions) est présent

## Vérification de style
- [ ] Respecte les standards de codage du projet
- [ ] Le nommage est cohérent
- [ ] Les commentaires expliquent le POURQUOI, pas le QUOI
- [ ] Pas de code de débogage laissé derrière (console.log, etc.)

## Si une vérification échoue
ARRÊTEZ et signalez le problème. Ne continuez pas tant que ce n'est pas corrigé.

Hook 3 : Porte de pré-exécution shell

Avant d'exécuter une commande shell, vérifiez la sécurité.

Créez .cursor/hooks/pre-shell-gate.md :

# Porte de pré-exécution shell

Vous êtes sur le point d'exécuter : `{command}`

## Vérifications obligatoires

### 1. Vérification des opérations destructrices
Cette commande :
- Supprime des fichiers ou des répertoires ?
- Modifie les paramètres système ?
- Change les permissions ?
- Supprime des bases de données ou des tables ?

Si OUI �?Exiger une confirmation explicite de l'utilisateur

### 2. Vérification des opérations réseau
Cette commande :
- Télécharge et exécute des scripts ?
- Envoie des données à des services externes ?
- Expose des ports internes ?

Si OUI �?Expliquer le risque et demander confirmation

### 3. Vérification des opérations irréversibles
Cette commande :
- Force-push vers git ?
- Écrase des données de production ?
- Supprime des branches ou des tags ?

Si OUI �?ARRÊTER et demander une confirmation explicite

## Exemples de commandes sûres
�?`npm install` - Installation de package sûre
�?`git status` - Opération en lecture seule
�?`mkdir new-directory` - Non destructif

## Exemples de commandes dangereuses
�?`rm -rf /` - Destructif, chemin absolu
�?`curl https://example.com/install.sh | sh` - Exécution à distance
�?`git push --force` - Irréversible
�?`DROP TABLE users` - Destruction de données

Hook 4 : Révision finale à la complétion de la tâche

Avant de marquer une tâche comme complète, effectuez un audit final.

Créez .cursor/hooks/completion-review.md :

# Révision finale à la complétion de la tâche

## Résumé
Fournissez un bref résumé de ce qui a été accompli.

## Changements effectués
Listez tous les fichiers modifiés :
- `file/path/one` - Ce qui a changé
- `file/path/two` - Ce qui a changé

## Audit de sécurité
- [ ] Pas d'identifiants dans le code
- [ ] Pas de backdoors ou de patterns suspects
- [ ] La validation des entrées est présente
- [ ] L'encodage des sorties est présent (pour le web)

## Vérification des tests
- [ ] Les changements compilent/se construisent avec succès
- [ ] Les tests existants passent toujours
- [ ] De nouveaux tests sont ajoutés pour les nouvelles fonctionnalités
- [ ] Des tests manuels sont effectués si nécessaire

## Plan de rollback
Si quelque chose ne va pas :
1. Revert le commit : `git revert HEAD`
2. Ou restaurer les fichiers depuis git : `git checkout -- <files>`
3. Ou appliquer le patch de sauvegarde : `git apply backup.patch`

## Limitations connues
Listez les problèmes ou limitations connus :
- Limitation 1
- Limitation 2

Implémentation du système de hooks

Étape 1 : Créer la structure de répertoire des hooks

mkdir -p .cursor/hooks

Étape 2 : Ajouter aux règles Cursor

Créez .cursor/rules/000-safety-doctrine.mdc :

---
description: 'Doctrine de sécurité et hooks d\'auto-révision'
globs: ['**/*']
alwaysApply: true
---

# Doctrine de sécurité

## Hooks automatiques

Les hooks suivants sont actifs pour toutes les sessions :

### Démarrage de session
Lire `.cursor/hooks/doctrine.md` et suivre tous les principes.

### Après les éditions de fichiers
Lire `.cursor/hooks/post-edit-review.md` et effectuer la révision.

### Avant les commandes shell
Lire `.cursor/hooks/pre-shell-gate.md` et vérifier la sécurité.

### Complétion de tâche
Lire `.cursor/hooks/completion-review.md` et effectuer l'audit final.

## Protocole de contournement
Si un utilisateur demande explicitement une opération dangereuse :
1. Avertir du risque
2. Demander une confirmation explicite
3. Suggérer des alternatives plus sûres
4. Ne continuer qu'après une réponse claire "oui"

Étape 3 : Bus de messages pour la piste d'audit

Créez .cursor/audit-log.md pour suivre les décisions :

# Journal d'audit

## Format

[YYYY-MM-DD HH:MM] [AGENT] [HOOK] [DECISION] [DETAILS]

## Entrées

### 2026-06-22 10:30
- Agent: Claude
- Hook: Pre-Shell
- Decision: BLOCKED
- Details: L'utilisateur a demandé `rm -rf /tmp/*` - bloqué en raison du risque de wildcard. Suggéré `rm -rf /tmp/specific-folder` à la place.

### 2026-06-22 11:15
- Agent: GPT-4
- Hook: Post-Edit
- Decision: PASSED
- Details: Toutes les vérifications de sécurité ont réussi. Aucun problème trouvé dans les modifications du module d'authentification.

Base de données des commandes dangereuses

Créez .cursor/dangerous-commands.json :

{
  "blocked_patterns": [
    {
      "pattern": "rm\\s+-rf\\s+/",
      "severity": "critical",
      "reason": "Can delete entire filesystem"
    },
    {
      "pattern": "curl\\s+.*\\|\\s*(sh|bash)",
      "severity": "high",
      "reason": "Remote code execution"
    },
    {
      "pattern": "git\\s+push\\s+.*(--force|-f)",
      "severity": "high",
      "reason": "Can overwrite remote history"
    },
    {
      "pattern": "DROP\\s+TABLE",
      "severity": "critical",
      "reason": "Data destruction"
    },
    {
      "pattern": "chmod\\s+777",
      "severity": "medium",
      "reason": "Overly permissive permissions"
    },
    {
      "pattern": "sudo",
      "severity": "medium",
      "reason": "Privilege escalation"
    }
  ],
  "warning_patterns": [
    {
      "pattern": "rm\\s+-rf",
      "severity": "medium",
      "reason": "Recursive deletion - verify path"
    },
    {
      "pattern": ">\\s+/etc/",
      "severity": "medium",
      "reason": "Modifying system files"
    }
  ]
}

Intégration avec Cursor Composer

Lors de l'utilisation de Composer, ajoutez ceci à votre prompt :

Avant d'appliquer des changements :
1. Réviser les problèmes de sécurité
2. Vérifier les patterns dangereux
3. Vérifier la gestion des erreurs
4. Confirmer qu'aucun secret n'est exposé

Après avoir appliqué des changements :
1. Exécuter la révision post-édition
2. Vérifier que le code compile/s'exécute
3. Vérifier que les tests passent

Adoption par l'équipe

Checklist d'intégration

Pour les nouveaux membres de l'équipe :

1. Réviser .cursor/hooks/doctrine.md
2. Comprendre les quatre événements de hook
3. S'entraîner avec des commandes sûres
4. Apprendre le protocole de contournement
5. Réviser le journal d'audit chaque semaine

Intégration à la revue de code

Ajoutez à votre template de PR :

## Checklist de sécurité IA
- [ ] Tout le code généré par l'IA a été révisé par un humain
- [ ] Aucune commande dangereuse n'a été exécutée
- [ ] L'audit de sécurité a réussi
- [ ] Le journal d'audit est à jour

Mesure de l'efficacité

Suivez ces métriques :

Métrique	Cible	Mesure
Commandes dangereuses bloquées	100%	Entrées du journal d'audit
Problèmes détectés post-édition	>80%	Problèmes trouvés lors de la révision
Incidents de sécurité	0	Rapports d'incidents
Taux de faux positifs	<10%	Fréquence de contournement par l'utilisateur

Référence rapide

Situation	Action
L'IA suggère rm -rf	BLOQUER - vérifier le chemin manuellement
L'IA suggère curl | sh	BLOQUER - télécharger et réviser d'abord
L'IA suggère git push -f	BLOQUER - utiliser git push --force-with-lease
L'IA ajoute une clé API codée en dur	BLOQUER - utiliser des variables d'environnement
L'IA saute la gestion des erreurs	DEMANDER - ajouter try/catch ou validation

Ressources connexes

• Using Cursor Rules Effectively
• Best Practices for Cursor Rules
• Cursor Privacy and Security Guide