Guide complet Cursor Rules : faire générer du code conforme par l'IA (config pratique incluse)

Je fixe le code que Cursor vient de générer, doigt suspendu au-dessus de Entrée — troisième tentative.

La première fois, il a utilisé var. La deuxième, un composant classe. Cette fois, il a supprimé tous les types TypeScript et empilé des any. Je efface tout, prêt à coder à la main.

Là, j’ai compris : l’IA n’est pas bête — on ne lui a jamais dit « nos règles ».

Au début avec Cursor, je pensais qu’elle « savait » ce qu’est du bon code. Puis l’équipe s’est plainte : « pourquoi tes composants Cursor ne ressemblent pas au nôtre ? » Il fallait des normes explicites.

Cet article règle ce problème. Cinq minutes pour configurer Cursor Rules, et l’IA produit du code conforme — bon stack, bon style, sans surprises.

Qu’est-ce que Cursor Rules ? Pourquoi en avoir besoin ?

L’essence de Cursor Rules : fixer les règles à l’IA

En bref, Cursor Rules est un fichier de configuration qui indique à l’IA vos normes de codage.

Comme le manuel remis aux nouveaux développeurs : stack, nommage, organisation des fichiers. Cursor Rules, c’est le même principe — le « guide d’onboarding » de l’IA.

Le mécanisme est direct : à chaque conversation, le contenu des règles est injecté dans le prompt. L’IA lit « ce projet utilise React Hooks, pas de composants classe » et génère en conséquence.

Sans Rules ? Mes erreurs au début

Ma première semaine avec Cursor, j’étais euphorique — l’IA code vite. Trois jours plus tard, le désastre :

Style incohérent. camelCase ici, PascalCase là, snake_case ailleurs. Impossible de s’y retrouver.

Mauvais stack. Je voulais des composants fonctionnels ; Cursor générait des class Component extends React.Component. Je disais « utilise Hooks », le fichier suivant revenait en arrière.

Normes ignorées. L’équipe exige des commentaires sur chaque fonction — code nu. Gestion d’erreurs : try-catch obligatoire, l’IA appelait l’API sans filet.

Deux jours de refactor ensuite, mains dans le plâtre.

Après configuration ? Le changement

Cinq minutes pour un fichier .cursorrules :

• React 18 + TypeScript
• Composants fonctionnels et Hooks uniquement
• Nommage camelCase uniforme
• Typage obligatoire, pas de any

Résultat ?

Chaque composant conforme. Cohérence +80 %, code review divisée par deux. L’équipe demandait : « comment tu fais pour que Cursor obéisse ? »

Les chiffres parlent : bien configurées, les Rules améliorent nettement la cohérence et réduisent le refactor. awesome-cursorrules dépasse 2000 stars — un vrai besoin des développeurs.

Configuration Cursor Rules (2026)

Ancien vs nouveau

Les tutoriels mentionnent .cursorrules ou .cursor/rules. Les deux existent, à des époques différentes.

Ancien (avant 2025) :
Un fichier .cursorrules à la racine, toutes les règles dedans. Simple.

Nouveau (recommandé 2026) :
Dossier .cursor/rules avec plusieurs .mdc par catégorie.

La migration est recommandée : règles modulaires et portées configurables. L’ancien format fonctionne encore, mais sera déprécié.

Alibaba Cloud - Choix n°1 des développeurs, 15 % de réduction exclusive sur Lighthouse

Obtenir -15 % →Pub

Mon conseil : nouveau projet → nouvelle méthode ; ancien → migrer quand vous avez le temps.

Deux niveaux : global vs projet

User Rules (global)

Vos préférences personnelles, tous projets confondus.

Chemin : File → Preferences → Cursor Settings → Rules → User Rules

Exemples :

• « TypeScript partout »
• « Pas de var, const ou let »
• « async/await, pas de .then() »

Vos « obsessions de code » personnelles.

Project Rules (projet)

Normes spécifiques au projet courant.

Configuration :

1. Créer .cursor à la racine
2. Créer rules dedans
3. Ajouter des .mdc : frontend.mdc, typescript-rules.mdc

Exemples :

• « Projet Next.js 14 + TypeScript + Tailwind CSS »
• « API RESTful »
• « Composants dans components/, nommage PascalCase »

Priorité : règles projet > règles globales.

Portée d’application : ne pas tout charger

Fonctionnalité 2026 : contrôler quand une règle s’applique.

Dans un .mdc :

Always : toujours actif. Pour les règles core (« pas de var »). Attention au contexte saturé.

Auto Attached : selon le type de fichier. Ex. règles React sur .tsx, Python sur .py. Ma recommandation principale.

Agent Requested : l’IA décide selon la conversation. Règles auxiliaires.

Manual : sur demande explicite. Perf, tests, cas particuliers.

En pratique : 80 % Auto Attached, 10 % Always, 10 % le reste.

Nouveauté janvier 2026 : commande /rules

Le 8 janvier 2026, Cursor CLI ajoute /rules : créer et éditer les règles depuis le terminal, sans chercher les dossiers.

Voir l’annonce officielle.

Comment rédiger des Cursor Rules efficaces ?

La qualité des règles détermine si Cursor obéit.

Trois catégories de contenu

A. Technique et architecture

Décrire le projet :

Stack du projet :
- Frontend : React 18 + TypeScript 5.3
- State : Zustand
- Styles : Tailwind CSS 3.4
- Build : Vite 5.0
- Node.js : 18+

Architecture :

Normes d'architecture :
- Frontend/backend séparés
- API RESTful
- Structure :
  - components/ composants réutilisables
  - pages/ pages
  - utils/ utilitaires
  - hooks/ hooks personnalisés

Pourquoi autant de détails ?

J’avais écrit « React » sans version — parfois React 16, parfois 18. Les numéros de version ont tout réglé.

B. Normes de code

Normes de code :

Nommage :
- Composants : PascalCase (ex. UserProfile)
- Fichiers : kebab-case (ex. user-profile.tsx)
- Variables/fonctions : camelCase (ex. getUserData)
- Constantes : UPPER_SNAKE_CASE (ex. MAX_RETRY_COUNT)

Style :
- Composants fonctionnels uniquement
- const > let, pas de var
- Fonctions fléchées (sauf besoin de this)
- Typage TypeScript obligatoire

Longueur :
- Fichier max 300 lignes
- Fonction max 50 lignes

Commentaires :
- JSDoc sur les fonctions clés
- Commentaires inline sur la logique complexe
- Expliquer le « pourquoi », pas le « quoi »

C. Qualité et tests

Gestion d'erreurs :
- try-catch sur toutes les opérations async
- Messages d'erreur utilisateur clairs
- Ne pas avaler les erreurs — au minimum console.error

Performance :
- key sur les listes
- Virtualisation pour grandes listes
- width/height sur les images

Tests :
- Tests unitaires sur les utilitaires
- Couverture sur la logique métier critique

Principes d’or

Principe 1 : concret, exécutable, vérifiable

❌ « Bon code », « bonnes pratiques », « attention à la perf »

✅ :

• « Composants fonctionnels, pas de classes »
• « Props en interface, pas en type »
• « async/await obligatoire, pas de .then() »

Des instructions, pas des vœux.

KiloClaw - OpenClaw managé pour l’entreprise : orchestration d’agents IA et routage intelligent

Commencer →Pub

Principe 2 : max 500 lignes

Trop long = contexte saturé, compréhension difficile. Diviser :

• frontend.mdc, backend.mdc, typescript.mdc, testing.mdc

Principe 3 : exemples de code

❌ « Composants fonctionnels avec types »

✅ :

Exemple de composant :

interface UserCardProps {
  name: string;
  email: string;
}

export const UserCard = ({ name, email }: UserCardProps) => {
  return (
    <div className="user-card">
      <h3>{name}</h3>
      <p>{email}</p>
    </div>
  );
};

Principe 4 : règles importantes en tête

1. Stack et versions
2. Style de code
3. Organisation des fichiers
4. Optimisations optionnelles

Erreurs courantes

Erreur 1 : trop vague

« Bonnes pratiques React » — lesquelles, 2016 ou 2024 ?

→ « React Hooks, useState/useEffect, état complexe en useReducer »

Erreur 2 : règles contradictoires

« TypeScript obligatoire » + « any autorisé » — l’IA hésite et ignore tout.

Erreur 3 : versions oubliées

React 16 (classes) vs React 18 (Hooks). Précisez : React 18.2+, TypeScript 5.3+, Node.js 18+.

Erreur 4 : dissertation

❌ « Nous choisissons TypeScript pour le typage statique… » (300 mots de plus)

✅ « TypeScript obligatoire, pas de any »

Cas pratique : React + TypeScript

Stack :

• React 18
• TypeScript 5.x
• Tailwind CSS 3.x
• Vite 5.x

Normes :

• Composants fonctionnels
• Typage strict, pas de any
• Nommage uniforme
• Gestion d’erreurs

Étape 1 : créer le fichier

mkdir -p .cursor/rules
cd .cursor/rules
touch react-typescript.mdc

Étape 2 : stack

# Règles projet React + TypeScript

## Stack

- React 18.2+
- TypeScript 5.3+
- Tailwind CSS 3.4+
- Vite 5.0+
- Node.js 18+

## Gestion des dépendances

- Gestionnaire : pnpm
- Ne pas utiliser npm ou yarn

Étape 3 : style de code

## Normes de code

### Composants

- Composants fonctionnels uniquement
- Nom PascalCase, fichier kebab-case
- Export nommé, pas de default

Exemple :

// ❌ Incorrect
export default function userProfile() { }

// ✅ Correct
export const UserProfile = () => { }

### TypeScript

- Typage obligatoire
- Props en interface, pas en type
- Pas de any — unknown ou type concret
- Type de retour explicite

Exemple :

interface UserCardProps {
  name: string;
  email: string;
  age?: number;
}

export const UserCard = ({ name, email, age }: UserCardProps): JSX.Element => {
  return (
    <div className="p-4 border rounded">
      <h3 className="text-lg font-bold">{name}</h3>
      <p className="text-gray-600">{email}</p>
      {age && <p>Age: {age}</p>}
    </div>
  );
};

### Nommage

- Variables/fonctions : camelCase
- Composants : PascalCase
- Constantes : UPPER_SNAKE_CASE
- Fichiers : kebab-case
- CSS : classes Tailwind, pas de CSS custom

### Async

- async/await uniquement
- Pas de chaînage .then()
- try-catch obligatoire

Exemple :

const fetchUserData = async (userId: string): Promise<User> => {
  try {
    const response = await fetch(`/api/users/${userId}`);
    if (!response.ok) throw new Error('Failed to fetch user');
    return await response.json();
  } catch (error) {
    console.error('Error fetching user:', error);
    throw error;
  }
};

Étape 4 : organisation

## Organisation

### Structure

src/
├── components/     # Composants réutilisables
├── pages/          # Pages
├── hooks/          # Hooks custom
├── utils/          # Utilitaires
├── types/          # Types TypeScript
├── services/       # Appels API
└── constants/      # Constantes

### Nommage des fichiers

- Composant : user-card.tsx
- Utilitaire : format-date.ts
- Types : user.types.ts
- Hook : use-user-data.ts

### Ordre des imports

1. React
2. Bibliothèques tierces
3. Composants internes
4. Utilitaires
5. Types
6. Styles

Étape 5 : qualité

## Qualité

### Erreurs

- try-catch sur les appels API
- Messages utilisateur clairs
- Logs d'erreur

### Performance

- key sur les listes
- Pas de nouvel objets/fonctions dans le render
- React.memo si pertinent
- width/height sur les images

### Code

- Fichier max 300 lignes
- Fonction max 50 lignes
- Commentaires sur logique complexe
- JSDoc sur fonctions clés

Étape 6 : fichier complet

Assemblez le tout dans .cursor/rules/react-typescript.mdc. Adaptez : Redux, React Query, règles métier.

Test

Prompt : « Crée un composant carte utilisateur avec nom, email et avatar »

Avant Rules :

export default function UserCard(props) {
  return <div>...</div>
}

Après Rules :

interface UserCardProps {
  name: string;
  email: string;
  avatarUrl: string;
}

export const UserCard = ({ name, email, avatarUrl }: UserCardProps): JSX.Element => {
  return (
    <div className="p-4 border rounded shadow">
      <img src={avatarUrl} alt={name} className="w-16 h-16 rounded-full" width="64" height="64" />
      <h3 className="text-lg font-bold mt-2">{name}</h3>
      <p className="text-gray-600">{email}</p>
    </div>
  );
};

Conforme du premier coup : composant fonctionnel, types, export nommé, Tailwind, dimensions image.

Techniques avancées et FAQ

Priorité des règles

Règles projet > règles globales

Global dit guillemets simples, projet dit doubles — le projet gagne.

Règles sous-dossier > parent

project/
├── .cursor/rules/general.mdc
└── frontend/
    └── .cursor/rules/react.mdc

Dans frontend/, react.mdc prime.

Appel manuel > déclenchement auto

Mention explicite d’une règle Manual → priorité même si scope Manual.

Vultr - Serveur cloud NVMe haute performance, 32 emplacements mondiaux, déploiement Docker en un clic

Voir les tarifs →Pub

Gestion multi-fichiers

.cursor/rules/
├── core.mdc              # Stack (Always)
├── frontend.mdc          # Frontend (Auto Attached: *.tsx, *.ts)
├── backend.mdc           # Backend (Auto Attached: *.py, *.go)
├── testing.mdc           # Tests (Auto Attached: *.test.*)
└── performance.mdc       # Perf (Manual)

Débogage

Règles chargées ?

Demandez : « Quelles règles vois-tu ? » Pas listées → chemin, portée ou format incorrect.

Conflits

Deux règles contradictoires → l’IA peut tout ignorer. Trouvez le conflit, supprimez la règle faible ou précisez « override ».

L’IA désobéit

1. Règles vagues → instructions précises
2. Fichier trop long → règles importantes en tête
3. Prompt contradictoire → « suis les règles du projet »
4. Ajoutez des exemples, passez en Always

Ressources communautaires

awesome-cursorrules — 2000+ stars : React, Vue, Python, Go, Next.js, Astro, TypeScript, tests, Docker.

awesome-cursorrules-zh — règles fusionnées full-stack (React + FastAPI).

cursor.directory — bibliothèque web, 30+ frameworks.

dotcursorrules.com — cas pratiques et bonnes pratiques.

Conseil : partir du communautaire, ajuster après usage.

Collaboration

1. Git

git add .cursor/rules
git commit -m "Add Cursor rules for project standards"

Pull → règles chargées pour toute l’équipe.

2. README

## Développement avec Cursor

Règles dans `.cursor/rules` :
- React 18 + TypeScript
- Composants fonctionnels + Hooks
- Tailwind CSS
- Typage strict

Modifier les règles : discuter avec l'équipe d'abord.

3. Review trimestrielle

Règles obsolètes ? Nouvelles pratiques ? Retours équipe ? Document vivant.

Conclusion

En une phrase : fixez les règles, l’IA travaille bien.

Vous aussi, au début :

• Composants au style incohérent
• TypeScript avec des any cachés
• Code « trop IA », pas humain

Ce n’est pas Cursor — c’est nous qui n’avons pas défini les règles.

Maintenant :

1. Créer les fichiers — .cursor/rules pour les nouveaux, .cursorrules en transition
2. Stack explicite — versions, frameworks, outils
3. Normes de code — nommage, style, erreurs, exemples
4. ≤ 500 lignes — diviser si besoin
5. Itérer — document vivant

Agissez :

• Pas encore configuré ? 5 minutes pour le premier fichier
• Déjà configuré ? Vérifiez la clarté, ajoutez des exemples
• En équipe ? Versionnez dans Git

Dans un mois :

• Code review ÷ 2
• Style unifié
• Onboarding accéléré
• L’IA devient un vrai assistant

Ressources :

• awesome-cursorrules
• awesome-cursorrules-zh
• cursorrules.org