Accueil › Cursor › Cursor Rules

Cursor Rules : configurer l’IA pour qu’elle code comme vous

Les Cursor Rules sont des fichiers d’instructions persistantes qui indiquent à l’IA de Cursor comment coder dans votre projet : conventions, frameworks, style, patterns architecturaux. Un bon fichier de règles fait passer le taux d’acceptation des suggestions IA de ~30% à 80%+.

Sans règles personnalisées, l’IA de Cursor fait des choix génériques. Elle peut utiliser des class components au lieu de functional components, ignorer vos conventions de nommage, ou choisir des bibliothèques que vous n’utilisez pas. Les Cursor Rules résolvent ce problème en fournissant un « guide de style » persistant que l’IA consulte à chaque interaction, que ce soit dans le Chat, le Composer, l’édition inline (Cmd+K) ou le mode Agent.

En 2026, Cursor supporte deux systèmes de règles : le fichier legacy .cursorrules (un seul fichier à la racine du projet) et le nouveau système .cursor/rules/ avec des fichiers .mdc plus granulaires. Ce guide couvre les deux approches, avec des exemples concrets par framework.

Les trois types de règles dans Cursor

User Rules (globales)

Définies dans Settings > Cursor Settings > Rules. Ces règles s’appliquent à tous vos projets, quel que soit le dossier ouvert. Utilisez-les pour vos préférences personnelles universelles :

Répondez toujours en français.
Style concis, pas de répétitions inutiles.
Quand vous générez du code, incluez toujours la gestion d'erreurs.
Préférez les types explicites aux inférences dans TypeScript.

Gardez les User Rules courtes et universelles. Les instructions spécifiques au projet appartiennent aux Project Rules.

Project Rules : le fichier .cursorrules (legacy)

Créez un fichier .cursorrules à la racine de votre projet. Cursor le détecte automatiquement et applique son contenu à toutes les interactions IA dans ce projet. C’est l’approche la plus simple et la plus répandue.

# .cursorrules (exemple pour un projet Next.js 15)

## Stack technique
- Next.js 15 avec App Router
- TypeScript strict (strictNullChecks, noImplicitAny)
- Tailwind CSS pour le styling (pas de CSS inline)
- Prisma comme ORM
- Zod pour la validation
- React Hook Form pour les formulaires

## Conventions de code
- Functional components uniquement (pas de class components)
- Types de retour explicites sur toutes les fonctions exportées
- camelCase pour les variables et fonctions
- PascalCase pour les composants et types
- Fichiers en kebab-case (user-profile.tsx, pas UserProfile.tsx)
- Un composant par fichier

## Architecture
- Colocation : composants, hooks et utils proches des pages qui les utilisent
- Server Components par défaut, "use client" uniquement quand nécessaire
- Actions server pour les mutations (pas de routes API sauf webhooks)
- Gestion d'erreurs avec des error boundaries

## Instructions pour l'IA
- Ne modifie pas les fichiers de configuration sans demander
- Quand tu crées un composant, crée aussi le fichier de test
- Commente le code en français
- Ne génère pas de code que tu ne peux pas expliquer

Ce fichier doit être commité dans votre dépôt Git. Chaque membre de l’équipe bénéficie automatiquement des mêmes règles quand il ouvre le projet dans Cursor.

Project Rules : le format .mdc (nouveau)

Le nouveau système utilise des fichiers .mdc (Markdown avec métadonnées) dans le dossier .cursor/rules/. Chaque fichier peut être scopé à des fichiers spécifiques via des glob patterns, activé automatiquement ou manuellement, et focalisé sur un aspect précis.

# .cursor/rules/backend-services.mdc
---
description: Conventions pour les services backend
globs:
  - src/services/**/*.ts
alwaysApply: false
---

- Utiliser le pattern Repository pour l'accès aux données
- Injecter les dépendances via le constructeur
- Logger toutes les erreurs avec structlog
- Retourner des Result types au lieu de throw
- Noms de services en snake_case

Ce fichier ne s’applique qu’aux fichiers TypeScript dans src/services/. Quand l’IA travaille sur un fichier de ce dossier, les règles sont automatiquement chargées. Pour les fichiers d’un autre dossier, ces règles sont ignorées.

Vous pouvez créer autant de fichiers .mdc que nécessaire : un pour le frontend, un pour le backend, un pour les tests, un pour les migrations. Cette granularité évite de surcharger le contexte avec des règles non pertinentes.

Pour créer un nouveau fichier de règles, utilisez la palette de commandes : Cmd+Shift+P > « New Cursor Rule ».

AGENTS.md : les règles pour le mode Agent

En complément des fichiers de règles classiques, Cursor supporte un fichier AGENTS.md à la racine du projet (similaire au CLAUDE.md utilisé par Claude Code). Ce fichier contient des instructions spécifiques pour le mode Agent : comment naviguer dans le projet, quels outils utiliser, quelles précautions prendre lors des modifications automatiques.

# AGENTS.md

## Structure du projet
- /src/app : pages Next.js (App Router)
- /src/components : composants React réutilisables
- /src/lib : utilitaires et helpers
- /src/services : logique métier
- /prisma : schéma et migrations de base de données

## Règles pour l'Agent
- Toujours exécuter les tests après modification (npm test)
- Ne jamais modifier .env ou les fichiers de configuration de production
- Créer une migration Prisma quand le schéma change
- Vérifier les imports TypeScript après chaque modification de fichier
- Utiliser le linter avant de considérer une tâche terminée (npm run lint)

L’AGENTS.md est particulièrement utile pour les Cloud Agents qui travaillent de manière autonome. Il leur fournit le contexte nécessaire pour prendre des décisions architecturales cohérentes sans votre supervision directe.

Ordre de priorité des règles

Cursor évalue les règles dans cet ordre :

Les règles incluses manuellement avec @ruleName dans un prompt (priorité la plus haute). Les règles auto-attachées via les glob patterns (alwaysApply: false mais matchant le fichier en cours). Les règles en mode alwaysApply: true (chargées dans chaque conversation). Les User Rules (Settings > Rules). Le fichier legacy .cursorrules (priorité la plus basse).

Exemples de règles par framework

React / Next.js

# .cursorrules (React + Next.js 15)
- Next.js 15 App Router avec TypeScript strict
- Functional components avec hooks, jamais de class components
- Tailwind CSS uniquement (pas de styled-components, pas de CSS modules)
- Server Components par défaut, "use client" uniquement si nécessaire
- Zod pour toute validation de données
- Préférer les Server Actions aux routes API pour les mutations
- Utiliser next/image pour toutes les images
- Accessibilité : aria-labels sur tous les éléments interactifs
- Tests avec Vitest et Testing Library

Python / FastAPI

# .cursorrules (Python + FastAPI)
- Python 3.12+ avec type hints stricts
- FastAPI pour les endpoints, Pydantic v2 pour les modèles
- SQLAlchemy 2.0 avec le pattern async (pas de sync)
- Suivre PEP 8 et PEP 484
- Docstrings au format Google
- Logging avec structlog, pas print()
- Tests avec pytest et pytest-asyncio
- Gestion d'erreurs explicite (pas de except: générique)
- Nommage : snake_case pour fonctions et variables, PascalCase pour classes

Go

# .cursorrules (Go)
- Go 1.22+ avec modules
- Suivre Effective Go et les conventions du projet
- Gestion d'erreurs explicite (pas de panic sauf init)
- Interfaces courtes (1-3 méthodes), définies côté consommateur
- Tests dans le même package avec _test.go
- Utiliser context.Context comme premier paramètre des fonctions
- Nommage : exported = PascalCase, private = camelCase
- Pas de dépendances externes sauf approbation préalable

Rust

# .cursorrules (Rust)
- Rust 2024 edition avec clippy::pedantic
- Utiliser thiserror pour les types d'erreur custom
- Préférer &str à String dans les paramètres de fonction
- Implémenter Display pour tous les types d'erreur
- Documenter les fonctions publiques avec des exemples (/// # Examples)
- Tests unitaires dans le même fichier (#[cfg(test)] mod tests)
- Pas de unwrap() dans le code de production (utiliser ? ou expect avec message)
- Utiliser serde pour la sérialisation JSON

Migrer de .cursorrules vers .cursor/rules/

Si votre fichier .cursorrules est devenu trop long (200+ lignes), la migration vers le format .mdc est recommandée. Voici la procédure :

Créez le dossier .cursor/rules/ à la racine de votre projet. Identifiez les sections thématiques de votre .cursorrules (stack, conventions frontend, conventions backend, tests, comportement IA). Créez un fichier .mdc pour chaque section avec les globs appropriés. Conservez les règles universelles dans un fichier avec alwaysApply: true. Testez que les règles sont bien appliquées en demandant à l’IA « quelles règles appliques-tu ? » dans le Chat.

Exemple de structure après migration :

.cursor/
  rules/
    core.mdc              # Règles universelles (alwaysApply: true)
    frontend.mdc          # Globs: src/app/**/*.tsx, src/components/**/*.tsx
    backend.mdc           # Globs: src/services/**/*.ts, src/api/**/*.ts
    testing.mdc           # Globs: **/*.test.ts, **/*.spec.ts
    database.mdc          # Globs: prisma/**/*
    ai-behavior.mdc       # Règles de comportement IA (alwaysApply: true)

Vous pouvez garder le fichier .cursorrules en parallèle pendant la transition. Les deux systèmes coexistent, avec les fichiers .mdc prioritaires.

Bonnes pratiques pour rédiger des règles efficaces

Restez concis et direct

Les règles sont chargées dans le contexte à chaque interaction. Chaque mot compte dans le budget de tokens. Évitez les explications longues. Préférez des instructions courtes et impératives : « Utiliser X » plutôt que « Il est recommandé d’utiliser X parce que… ».

Objectif : moins de 500 lignes par fichier de règles. Si vos règles dépassent cette limite, divisez-les en plusieurs fichiers .mdc scopés.

Soyez spécifique sur le stack

Nommez les versions exactes des frameworks, les bibliothèques à utiliser (et celles à éviter), et les patterns architecturaux. « Utiliser React » est trop vague. « React 19 avec functional components, hooks, et Tailwind CSS v4 » est exploitable.

Incluez des instructions sur le comportement de l’IA

Les meilleures règles ne se limitent pas au style de code. Elles cadrent aussi le comportement de l’assistant :

# Instructions pour le comportement de l'IA
- Ne pas automatiquement accepter tout ce que je dis. Questionne si nécessaire.
- Quand tu modifies un fichier, vérifie que les imports sont corrects.
- Si une tâche est ambiguë, demande des précisions avant de coder.
- Ne génère pas de code que tu ne peux pas expliquer.
- Mentionne quelles règles tu appliques dans ta réponse.

Ce type d’instruction réduit le comportement « yes-man » de l’IA et produit du code plus fiable.

Renforcez les règles en cours de conversation

Après plusieurs échanges dans une même conversation, l’IA peut « oublier » les règles (le contexte récent prend le dessus). Ajoutez périodiquement « rappelle-toi des règles » ou « relis les .cursorrules » dans vos messages pour réactiver l’attention sur les conventions. C’est un contournement connu de la gestion de contexte des LLMs.

Versionnez et partagez vos règles

Commitez vos fichiers .cursorrules ou .cursor/rules/ dans Git. C’est de la documentation exécutable : un nouveau membre de l’équipe comprend les conventions du projet en lisant les règles, et son Cursor génère automatiquement du code conforme dès le premier jour.

Certaines équipes vont plus loin et traitent les Cursor Rules comme des dépendances versionnées. Un fichier de règles partagé entre plusieurs projets (conventions d’entreprise, normes de sécurité) peut être maintenu dans un dépôt central et importé dans chaque projet. C’est l’équivalent d’un ESLint config partagé, mais pour l’IA.

Testez vos règles

Après avoir créé ou modifié vos règles, testez-les explicitement. Ouvrez le Chat (Cmd+L) et demandez : « Quelles sont mes cursorrules ? » ou « Génère un composant React en suivant les conventions du projet. » Vérifiez que le code produit respecte vos règles. Si ce n’est pas le cas, reformulez les instructions. Les règles les plus efficaces sont celles qui utilisent un langage impératif court (« Utilise X », « Ne jamais Y ») plutôt que des phrases longues et nuancées.

Une astuce avancée recommandée par des développeurs expérimentés : ajoutez dans vos règles la directive « Mentionne quelles règles tu appliques dans chaque réponse ». Cela rend le suivi des règles transparent et vous permet d’identifier rapidement quand l’IA les ignore.

Ressources communautaires

Vous n’avez pas besoin de partir de zéro. La communauté Cursor a créé des dépôts de règles prêtes à l’emploi :

awesome-cursorrules (GitHub, PatrickJS) : le dépôt le plus complet, avec des règles pour React, Angular, Vue, Svelte, Python, Go, Rust, Flutter, Swift, et des dizaines d’autres stacks. Chaque fichier est directement utilisable.

cursor.directory : un annuaire web où vous pouvez parcourir, chercher et voter pour les règles de la communauté. Classé par framework et langage.

cursorrules.org : un guide spécialisé avec des exemples détaillés par framework et des explications des patterns.

L’extension VS Code vscode-cursor-rules permet de télécharger et installer des règles directement depuis la palette de commandes (Cmd+Shift+P > « Cursor Rules: Add .cursorrules »).

Verdict

Les Cursor Rules sont probablement la fonctionnalité la plus sous-estimée de Cursor. Un fichier de 50 lignes bien rédigé transforme l’expérience : le code généré respecte vos conventions dès le premier essai, les reviews de diffs sont plus rapides, et les itérations de correction diminuent drastiquement.

L’effort est minime (30 minutes pour créer un fichier de règles adapté à votre projet) et le retour sur investissement est immédiat. Si vous n’utilisez pas encore de règles, c’est la première chose à configurer dans Cursor.

Conseil : commencez par un fichier .cursorrules simple (stack, conventions, comportement IA). Testez pendant une semaine. Ajoutez des règles au fur et à mesure que vous identifiez les points où l’IA s’écarte de vos attentes. Quand le fichier dépasse 200 lignes, migrez vers le format .mdc avec des fichiers scopés.