Cursor Rules : configurer ses règles avec 3 exemples

L’intérêt : moins de corrections à demander en revue de code. Prenons un exemple purement illustratif : quatre développeurs qui effectuent chacun trois corrections de cinq minutes par semaine passent 60 minutes à rappeler les conventions. Ce n’est pas une promesse de gain. Comptez les corrections qui disparaissent après la mise en place des règles, puis déduisez le temps consacré à leur maintenance. Le coût de l’abonnement est une autre question, traitée dans notre article sur les tarifs de Cursor.

Où placer ses Cursor Rules ?

Les décisions de développement communes ont leur place à côté du code. Les préférences personnelles de réponse doivent rester personnelles.

Les consignes des fichiers AGENTS.md placés dans les sous-répertoires s’appliquent à leur répertoire et à ses descendants. Elles se combinent avec celles des répertoires parents ; les plus spécifiques prennent le pas sur les autres. Pour les règles d’équipe, de projet et personnelles, l’ordre de priorité documenté en cas de conflit est Team → Project → User. Documentation des règles Cursor

Pour une petite équipe, je privilégie les règles de projet. Une consigne comme « utilisez nos composants de formulaire existants » concerne le dépôt. « Répondez brièvement à la fin » relève de vos préférences. Séparer les deux évite qu’une préférence personnelle devienne, par accident, une règle pour toute l’équipe.

Quand faut-il joindre chaque règle au contexte ?

Le frontmatter, ce petit bloc de paramètres placé au-dessus du texte d’une règle, détermine quand elle est jointe au contexte.

Lorsque le choix revient à l’agent, celui-ci sélectionne la règle à partir de sa description. Un glob est un motif de correspondance pour les chemins de fichiers. Déclenchement et syntaxe des règles

Voyez ce mécanisme comme l’acheminement d’une fiche de travail vers le bon poste. Même parfaitement rédigée, une consigne ne sert à rien si elle n’arrive jamais jusqu’à la tâche concernée. Appliquez le socle de sécurité partout, adressez les conventions de style aux fichiers concernés et réservez le choix de l’agent aux consignes dont la pertinence dépend de la tâche.

Trois règles à copier pour une application web TypeScript

Créez les fichiers suivants dans votre dépôt. Ce sont des conventions d’équipe proposées à titre d’exemple, qui utilisent les champs de frontmatter et la syntaxe des motifs décrits dans la documentation de Cursor. Les consignes qu’ils contiennent sont des points de départ à adapter, pas des normes de développement imposées par Cursor.

Style : cibler les fichiers TypeScript

Enregistrez ce contenu dans .cursor/rules/style.mdc :

---
globs: src/**/*.ts, src/**/*.tsx
alwaysApply: false
---

- Follow the nearest existing module's naming and import conventions.
- Prefer named exports unless the framework requires a default export.
- Reuse existing UI components and utilities before adding alternatives.
- Keep formatting in the repository's formatter and linter configuration.

Cet exemple suppose que le code de l’application se trouve dans src/ ; adaptez les chemins à votre dépôt. Il porte volontairement sur des choix qu’un outil de formatage ne peut pas trancher, comme l’existence d’un bouton ou d’un utilitaire de gestion des dates déjà adapté au besoin. Modifiez la préférence d’export si votre équipe a fait un autre choix. Une règle doit décrire votre dépôt, pas en revoir discrètement la conception.

Tests : décrire les tâches qui en ont besoin

Enregistrez ce contenu dans .cursor/rules/tests.mdc :

---
description: Testing requirements when adding features, fixing bugs, or changing TypeScript behavior
alwaysApply: false
---

- Cover changed behavior with a focused regression test.
- Use the existing test runner, fixtures, and file naming conventions.
- Read package.json for the relevant test script; do not invent a command.
- Report the command and actual result, or explain why tests were not run.

Le résultat attendu : un test utile et un compte rendu fidèle à ce qui a été exécuté. Une correction de bug doit laisser une preuve que le problème d’origine est couvert. Une refactorisation doit préserver le comportement concerné. Ni l’une ni l’autre ne nécessite un second framework de test ou un rapport qui confond « test écrit » et « test réussi ».

Pour demander explicitement cette liste de vérifications, ajoutez @tests à votre requête. Si votre équipe veut l’appliquer à chaque tâche, passez son mode à Always Apply. Faites-en un choix d’équipe assumé : avec la description seule, la sélection reste à la discrétion de l’agent.

Sécurité : garder un socle court

Enregistrez ce contenu dans .cursor/rules/security.mdc :

---
alwaysApply: true
---

- Never put secrets in source code, test fixtures, or application logs.
- Use existing server-side authentication and authorization helpers.
- Validate untrusted input at server boundaries with the existing schemas.
- Do not remove permission checks to make a feature or test pass.

Remplacez la référence aux utilitaires existants par les chemins réels des modules de votre dépôt, dès que vous les connaissez. Ce socle doit rester facile à comprendre pendant le développement d’une fonctionnalité ordinaire. « Rendez le code sûr » donne peu de prise à la personne qui relit ; « conservez le contrôle des autorisations » énonce une exigence concrète.

Ce fichier fournit des consignes ; il ne constitue pas une barrière de sécurité. Continuez à faire respecter les contrôles d’accès dans le code et à examiner les modifications sensibles. Cursor met lui-même en garde contre le fait de s’appuyer uniquement sur les consignes données à l’IA pour assurer la sécurité. Recommandations sur les règles d’équipe

Vérifier la configuration sur une vraie modification

Choisissez une petite tâche qui entraînait jusque-là des corrections répétées. Modifier la validation d’un formulaire est un bon cas d’essai : cela touche un composant, modifie un comportement et traite des données saisies par l’utilisateur.

1. Notez le résultat attendu. Nommez le composant existant à réutiliser, le comportement à tester et le point de validation à préserver.
2. Enregistrez les trois fichiers et vérifiez leur statut. Cursor affiche les règles dans Customize → Rules ; la commande /create-rule est également disponible dans Agent. Créer une règle
3. Demandez la modification en plaçant les fichiers concernés dans le contexte. Gardez une demande réaliste. Une tâche qui répète toutes les règles ne permet pas de savoir si la configuration a aidé.
4. Examinez le diff et les vérifications rapportées. Cherchez la convention effectivement appliquée, pas une déclaration affirmant que les règles ont été suivies. Si la liste de vérifications des tests compte pour cet essai, demandez explicitement @tests.
5. Incluez les règles utiles dans le commit de la modification. Donnez à l’équipe un point de départ qu’elle peut relire. Précisez une phrase vague avant d’ajouter un nouveau fichier.

Si une convention n’est pas respectée, distinguez deux causes : la règle n’a pas été jointe à la tâche, ou elle l’a été sans produire l’effet attendu. Dans le premier cas, corrigez son déclenchement. Dans le second, clarifiez la consigne, ajoutez un exemple ou mettez en place une vérification automatisée.

Quelles conventions méritent une règle ?

Commencez par les erreurs répétées qui coûtent le plus à votre équipe. Voici des usages concrets à envisager, classés selon la charge de revue qu’ils pourraient éviter.

N’y voyez pas une obligation de créer cinq fichiers supplémentaires. Si un problème ne s’est jamais présenté, laissez-le de côté. Si une machine peut vérifier précisément l’exigence, privilégiez ce contrôle. Une règle utile comble un manque entre la demande liée à la tâche et l’outillage déjà présent dans le dépôt.

Que faire de l’ancien fichier .cursorrules ?

Pour la configuration de projet actuellement documentée, utilisez .cursor/rules/*.mdc. Au 11 octobre 2026, la page consacrée aux règles ne mentionne pas .cursorrules : elle ne permet donc pas de confirmer si cet ancien fichier fonctionne encore. Documentation actuelle

Si votre dépôt contient toujours l’ancien fichier, je recommande de transférer ses consignes utiles dans des règles de projet ciblées, en partant des trois fichiers ci-dessus. Choisissez leurs déclencheurs et vérifiez le résultat sur une vraie tâche avant de retirer l’ancienne copie. Ne conservez pas des conventions obsolètes au seul motif qu’elles sont déjà écrites.

Quel rapport avec CLAUDE.md et AGENTS.md ?

Le principe commun est celui de consignes de projet durables : Claude Code dispose de CLAUDE.md, et Codex lit les conventions de travail AGENTS.md. L’option Markdown simple de Cursor répond au même besoin, tandis que ses fichiers .mdc permettent de choisir quand les règles sont jointes au contexte. Gardez des conventions cohérentes entre les outils, mais configurez explicitement le chargement pour chacun : copier du texte ne revient pas à copier des paramètres. Si votre équipe utilise plusieurs agents, désignez un responsable des conventions communes pour éviter que les fichiers deviennent des références contradictoires.

Deux petits outils à envisager après la mise en place

Un outil de vérification des règles du dépôt est la piste la plus solide pour un responsable technique : il contrôlerait les extensions de fichiers, les champs de frontmatter reconnus et les motifs qui ne correspondent à aucun fichier suivi. Sa première version utile peut se limiter à un rapport local exécuté pendant la revue. Le signal de demande reste modeste : lors de la recherche menée pour cet article, DataForSEO a indiqué 140 recherches mensuelles estimées pour « cursor rules examples ». Cela montre un intérêt pour un sujet voisin, pas une volonté de payer. La limite est claire : une règle valide dans sa structure peut tout de même donner de mauvaises consignes. Définition de la métrique

Un dossier de revue des conventions d’équipe pourrait aider un responsable qui maintient plusieurs dépôts. Transformez les commentaires de revue récurrents et les exemples validés en une proposition de diff des règles, avec une personne désignée pour relire chaque modification. DataForSEO a indiqué 70 recherches mensuelles estimées pour « cursor team rules ». Commencez par un utilitaire interne : les Team Rules assurent déjà la distribution, ce qui laisse peu d’intérêt à un tableau de bord de stockage supplémentaire. La valeur se trouve dans le choix de ce qui mérite de devenir une consigne durable. Définition de la métrique

Questions fréquentes lors de la configuration

La semaine prochaine, choisissez une correction récurrente, précisez la règle correspondante et essayez-la sur la prochaine pull request ordinaire. Pour éclairer le choix de l’outil lui-même, lisez notre avis sur Cursor ou notre sélection des meilleures alternatives à Cursor.

Pour intégrer ces pratiques au workflow de développement d’une équipe, consultez l’offre systèmes d’IA en production.