Claude Skills vs règles Cursor : que choisir ?

Si vous codez avec l'IA en 2026, vous vous êtes sans doute retrouvé avec des instructions à deux endroits : un dossier .cursor/rules que Cursor lit, et un dossier de skills que Claude lit. Les deux résolvent le même problème, apprendre à votre IA comment fonctionne votre projet pour arrêter de vous répéter, et ils le résolvent assez différemment pour que le mauvais choix vous coûte des tokens, des soucis de synchronisation, ou les deux.

Nous faisons tourner SkillProof, où nous installons et testons des skills Claude sur une machine vierge avant de les référencer. Cela nous donne un point de vue précis sur cette comparaison : nous avons converti des dizaines de fichiers de règles en skills pendant nos tests, et nous avons vu les deux formats échouer de façons que leur documentation ne mentionne jamais.

En bref : les règles Cursor sont plus simples et vivent plus près de votre éditeur. Les skills Claude sont plus puissants et vous suivent d'un outil à l'autre. Les règles gagnent quand l'instruction doit s'appliquer à chaque fichier correspondant à un motif, toujours. Les skills gagnent quand l'instruction est conditionnelle, embarque des fichiers annexes, ou doit fonctionner en dehors d'un seul IDE. La plupart des développeurs qui utilisent les deux outils devraient garder les conventions de projet dans un fichier partagé et mettre tout ce qui est conditionnel dans des skills.

	Règles Cursor	Skills Claude
Portée	Par projet (.cursor/rules/) ou par utilisateur (paramètres)	Globale (~/.claude/skills/) ou par projet (.claude/skills/)
Déclenchement	Motifs glob, toujours actif, ou correspondance de description	Correspondance de description, décidée par le modèle
Contenu	Instructions en texte brut	Instructions plus scripts, modèles, fichiers de référence
Portabilité	Cursor uniquement	Claude Code, Claude Desktop, claude.ai, l'Agent SDK
Coût en contexte	Texte complet de la règle quand elle est attachée ; les règles toujours actives chargent à chaque requête	~100 tokens de métadonnées jusqu'au déclenchement, puis le corps
Écosystème	Vaste ; des milliers de .cursorrules partagés sur GitHub	Plus restreint mais en croissance ; inclut le set officiel d'Anthropic
Culture du test	Pratiquement inexistante	Majoritairement inexistante ; nous testons les nôtres

Passons au détail, car le tableau cache les parties intéressantes.

Ce que sont vraiment les règles Cursor

Cursor a deux générations de la même idée. Le fichier .cursorrules original se trouve à la racine du projet : un seul fichier texte d'instructions injecté dans chaque requête IA de ce dépôt. Il est déprécié mais toujours honoré, et une grande part des exemples publics l'utilisent encore.

Le système actuel est un dossier .cursor/rules/ de fichiers .mdc, chacun avec un frontmatter qui contrôle quand il s'applique. Quatre modes : Always (chaque requête), Auto Attached (se déclenche quand un fichier correspondant à un glob est dans le contexte, donc globs: *.tsx s'attache seulement pendant du travail React), Agent Requested (le modèle lit la description et décide), et Manual (seulement quand vous le mentionnez avec @). Cursor lit aussi AGENTS.md, ce qui compte plus loin dans cet article. Il existe aussi des règles au niveau utilisateur, définies dans les paramètres de Cursor, qui s'appliquent à tous les projets.

Si cela ressemble beaucoup au système de déclenchement d'un skill, c'est en partie vrai. Les règles Agent Requested correspondent à une description exactement comme les skills. La différence se joue dans ce qui se passe après le déclenchement, et on y arrive.

Là où les règles gagnent vraiment

Nous testons des skills Claude pour gagner notre vie, donc vous vous attendez sans doute à ce qu'on plaide pour les skills partout. On ne le fera pas, parce que les règles ont de vraies forces.

Les règles toujours actives sont plus simples à raisonner. Une règle avec alwaysApply: true est dans le contexte de chaque requête, point final. Aucun déclencheur qui peut rater, aucune description à mal formuler, aucune session de débogage du type « pourquoi ça ne s'est pas activé ». Quand nous testons des skills, l'échec de déclenchement est l'un des deux défauts les plus courants que nous trouvons. Les règles en mode always ou glob ne peuvent structurellement pas avoir ce défaut. Pour un petit ensemble de lois de projet strictes (« ne jamais toucher aux fichiers générés dans src/gen/ »), une règle bêtement toujours active bat une règle conditionnelle intelligente.

Le ciblage par glob est précis. globs: **/*.sql veut dire que vos conventions SQL s'attachent pendant le travail SQL et jamais autrement. Le mapping entre type de fichier et instruction est mécanique et prévisible. Les skills approximent cela avec le libellé de la description (« à utiliser en écrivant du SQL »), ce qui fonctionne bien en pratique mais reste un jugement du modèle plutôt qu'une correspondance de motif.

Ils vivent là où vous tapez. Les règles s'intègrent à l'auto-complétion Tab de Cursor, aux éditions inline, et au mode agent sans configuration. Rien à installer, aucune convention de dossier à apprendre au-delà de déposer des fichiers dans un répertoire.

L'écosystème est immense. Cherchez .cursorrules sur GitHub et vous trouverez des milliers de fichiers couvrant presque tous les frameworks. La qualité varie énormément, mais pas la couverture.

Ce que les skills font que les règles ne peuvent pas

Si vous découvrez le format, notre guide complet des skills Claude couvre l'anatomie. Voici la partie pertinente pour la comparaison.

Un déclenchement conditionnel avec une vraie économie derrière. Un skill se charge par étapes. Au démarrage, Claude ne lit que le nom et la description de chaque skill, environ 100 tokens. Le corps se charge quand la description correspond à votre requête. Les fichiers de référence se chargent encore plus tard, et seulement si nécessaire. Cinquante skills installés restent au repos à quelques milliers de tokens au total. Cinquante règles toujours actives seraient une catastrophe de contexte, c'est pourquoi Cursor plafonne et avertit sur la longueur des règles. La divulgation progressive permet à un skill d'être énorme sans être coûteux, et cela change ce que vous pouvez vous permettre d'écrire.

Des fichiers embarqués. Un skill est un dossier, pas un fichier. Le skill docx d'Anthropic embarque des scripts Python qui construisent des documents Word. Le skill skill-creator embarque des modèles et un harnais d'évaluation. Un skill de revue de code peut porter une grille de sévérité comme fichier de référence séparé qui ne se charge que pendant les revues. Les règles sont du texte décrivant ce que le modèle doit faire. Les skills peuvent inclure l'outillage pour le faire, et le modèle exécute le script au lieu d'improviser le résultat.

La portabilité. Un skill écrit pour Claude Code fonctionne aussi dans Claude Desktop, sur claude.ai, et dans tout ce qui est construit sur l'Agent SDK. Vos conventions git vous suivent du terminal au chat jusqu'à un agent personnalisé. Une règle Cursor fonctionne dans Cursor. Si vous changez un jour d'éditeur, ou utilisez Claude pour du travail hors éditeur comme l'écriture ou l'analyse de données, le format skill est celui qui survit au changement. C'est l'argument le plus fort en faveur des skills comme alternative aux règles Cursor : vous écrivez les instructions une fois et elles ne sont pas mariées à un seul produit.

Les skills peuvent agir, pas seulement conseiller. Parce que Claude Code exécute des commandes, un skill peut dire « lance ce script et colle le résultat » plutôt que « voici comment on pourrait formater le résultat ». L'écart entre décrire un comportement et le livrer est le même écart qu'entre un guide de style et un linter.

Ce que les règles font que les skills ne peuvent pas

Deux choses, et elles ne sont pas anodines.

Le contexte natif de l'IDE. Les règles participent à tout ce que fait Cursor : complétions pendant que vous tapez, éditions inline Cmd+K, panneau agent. Les skills fonctionnent là où Claude fonctionne, ce qui aujourd'hui signifie la CLI, l'app desktop et le web, pas à l'intérieur de l'éditeur d'une autre entreprise. Si tout votre usage de l'IA se passe dans la touche Tab de Cursor, les skills ne vous atteignent pas là-bas.

L'application par glob. Il n'existe pas d'équivalent skill à « attacher ces instructions dès qu'un fichier .proto est dans le contexte ». Le modèle décide à partir des descriptions, et même s'il est doué pour ça, ce n'est pas une garantie. Pour des instructions qui doivent correspondre au type de fichier plutôt qu'au type de tâche, les règles ciblées par glob sont le meilleur mécanisme, un point c'est tout.

Le chemin de migration, dans les deux sens

Convertir un fichier .cursorrules en skill

Prenez un fichier de règles typique :

You are an expert React and TypeScript developer.

- Functional components with hooks only, no classes
- Named exports, never default exports
- Tailwind for styling, no inline style objects
- All API calls go through src/lib/api.ts
- Tests in Vitest, colocated as *.test.tsx

La conversion consiste surtout à ajouter un déclencheur et une structure :

---
name: react-conventions
description: React/TypeScript conventions for this repo. Use when
  writing or reviewing components, hooks, styles, API calls, or
  frontend tests.
---

## Components
- Functional components with hooks. No class components.
- Named exports only. No default exports.

## Styling
- Tailwind utility classes. Never inline style objects.

## Data access
- Every API call goes through `src/lib/api.ts`. Do not call
  fetch directly from a component.

## Tests
- Vitest, colocated next to the component as `*.test.tsx`.

Déposez-le dans .claude/skills/react-conventions/SKILL.md et il se déclenche sur le travail frontend de ce dépôt. Trois choses ont changé et chacune compte. La ligne de persona (« You are an expert... ») a disparu parce qu'elle ne sert à rien ; le modèle ne devient pas meilleur en React parce qu'on lui dit qu'il est un expert. La description liste maintenant des activités concrètes, car ce champ est le déclencheur et les descriptions vagues sont la première raison pour laquelle les skills restent inactifs. Et les puces ont gagné des titres, puisque le corps d'un skill doit être lisible d'un coup d'œil par le modèle au chargement. Notre guide pour écrire des skills couvre en profondeur la partie rédaction de la description ; c'est l'étape que les gens ratent.

Pendant que vous y êtes, demandez-vous si une puce devrait devenir un fichier. Si vos règles décrivent un format de réponse API, mettez un vrai exemple de réponse dans un reference.json à côté du SKILL.md et pointez vers lui. Cette option n'existe simplement pas dans le format des règles.

Dans l'autre sens

Convertir un skill en règle Cursor revient à l'aplatir. Prenez le corps de votre SKILL.md, enlevez le frontmatter, et enregistrez-le comme .cursor/rules/react-conventions.mdc avec un nouveau frontmatter :

---
description: React/TypeScript conventions for this repo
globs: src/**/*.tsx,src/**/*.ts
alwaysApply: false
---

- Functional components with hooks. No class components.
- Named exports only. No default exports.
...

Vous perdez les fichiers embarqués, donc tout ce qui était un script devient une description de ce que le script faisait. Vous perdez la divulgation progressive, donc élaguez fort : un corps de skill de 3 000 tokens devrait devenir une règle de 500 tokens, en gardant seulement ce dont les modèles de Cursor ont vraiment besoin par requête. Gardez le glob serré pour que la règle ne taxe pas un travail sans rapport.

Faire tourner les deux sans vous dupliquer

Beaucoup de développeurs utilisent Cursor pour éditer et Claude Code pour le travail d'agent dans le même dépôt. Le piège consiste à maintenir deux copies des mêmes conventions qui divergent en un mois.

La solution qui a fonctionné pour nous : choisir une maison canonique par instruction, selon sa forme.

Les faits de projet partagés vont dans AGENTS.md. Les deux outils le lisent. Notes d'architecture, commandes de build, structure des répertoires, la liste « ne jamais toucher ces fichiers ». Un fichier, zéro duplication, et il sert aussi aux nouveaux arrivants humains.

Les instructions liées à un glob restent dans .cursor/rules. Les conventions par type de fichier qui doivent s'attacher mécaniquement dans l'éditeur.

Les instructions liées à une tâche et transversales aux outils deviennent des skills. Méthodologie de débogage, checklists de revue, procédures de release, tout ce qui a un script ou un modèle, tout ce que vous voulez aussi disponible dans Claude Desktop ou le chat.

Si une instruction doit vraiment exister dans les deux formats, faites de la règle un pointeur, pas une copie : un .mdc de deux lignes disant « les conventions pour X vivent dans .claude/skills/x/SKILL.md ; suivez-les » garde une seule source de vérité. Certaines équipes scriptent la conversion en CI à la place, régénérant les fichiers .mdc à partir des corps de SKILL.md à chaque commit. C'est plus de machinerie que ce dont la plupart des projets ont besoin, mais ça bat la dérive silencieuse sur une grande équipe.

Une chose à éviter : coller le même document de 2 000 mots verbatim dans les deux systèmes. Dans Cursor, ça gonfle chaque requête. Dans Claude, c'est en général le signe que le contenu devrait être scindé en un petit noyau toujours pertinent et un ensemble de skills conditionnels. C'est le même raisonnement que skills vs MCP : faire correspondre le mécanisme à la forme du problème plutôt que de forcer un outil à tout faire.

Personne ne teste les règles non plus

Voici la partie de cette comparaison que personne d'autre ne vous donnera, parce que c'est toute notre raison d'être.

Quand nous avons commencé à tester des skills Claude communautaires, environ la moitié échouait dès le premier essai : déclencheurs cassés, instructions que le modèle ne peut pas suivre, résultat pas meilleur que la ligne de base. Nous avons documenté la taxonomie des échecs dans pourquoi la moitié des skills Claude ne fonctionnent pas. La question inconfortable qui suit est de savoir si les milliers de fichiers .cursorrules partagés sur GitHub sont meilleurs.

Ils ne le sont pas, et structurellement ils ne peuvent pas l'être. Les mêmes incitations s'appliquent : les règles sont publiées depuis le workflow d'un seul auteur, jamais vérifiées sur une configuration vierge, jamais mesurées contre une ligne de base sans règle, et étoilées sur la qualité du README plutôt que sur les résultats. Quand nous avons disséqué des fichiers de règles populaires, nous trouvons les mêmes défauts pour lesquels nous pénalisons les skills. Du remplissage de persona qui consomme du contexte et ne change rien. Des instructions écrites pour une version de modèle vieille de deux générations. Des puces contradictoires (« sois concis » quarante lignes après « explique toujours ton raisonnement en détail »). Des règles si longues qu'elles évincent le code qu'elles sont censées améliorer.

Les règles évitent un mode d'échec, puisqu'une règle toujours active ne peut pas échouer à se déclencher. Tous les autres modes d'échec se transfèrent directement. Un document de convention qui dégrade le résultat est tout aussi nuisible dans les deux formats ; le format change juste la façon dont il est livré.

Donc, quel que soit le côté de cette comparaison où vous atterrissez, le conseil opérationnel est identique : n'installez pas de fichiers d'instructions partagés sur la foi. Comparez le résultat avec et sans les instructions sur une vraie tâche de votre propre projet. Dix minutes de comparaison valent mieux que n'importe quel nombre d'étoiles. Pour les skills, nous avons déjà fait ce travail dans notre collection testée pour le code, où des entrées comme systematic-debugging apportent des preuves avant/après plutôt que des promesses. Pour les règles Cursor, à notre connaissance, personne ne fait ce travail du tout. Tirez vos propres conclusions sur ce que valent la moitié d'entre elles.

FAQ

Claude Code peut-il lire directement mon fichier .cursorrules ? Pas automatiquement. Claude Code lit CLAUDE.md, AGENTS.md, et ses dossiers de skills, et ignore .cursorrules et .cursor/rules. Vous pouvez lui demander de lire le fichier pendant une session, mais pour tout ce qui est permanent, convertissez le contenu en skill ou déplacez les parties partagées vers AGENTS.md.

Les règles Cursor coûtent-elles des tokens comme les skills ? Plus, dans la plupart des configurations. Une règle toujours active accompagne chaque requête à sa pleine longueur. Un skill reste au repos à environ 100 tokens de métadonnées et ne paie pour son corps que lorsqu'il est déclenché. Les règles ciblées par glob réduisent l'écart, puisqu'elles ne s'attachent que pendant le travail correspondant, mais il n'existe pas d'équivalent en règles au chargement de matériel de référence à la demande.

Dois-je convertir toutes mes règles Cursor en skills ? Non. Gardez les conventions ciblées par glob, liées au type de fichier, en tant que règles si vous travaillez dans Cursor ; ce mécanisme est vraiment meilleur pour elles. Convertissez le matériel lié aux tâches : workflows, checklists, tout ce qui a des modèles ou des scripts, tout ce que vous voulez en dehors de l'éditeur.

Existe-t-il un standard partagé que les deux outils lisent ? AGENTS.md est ce qui s'en rapproche le plus. Cursor et Claude Code le lisent tous les deux, ainsi qu'une liste croissante d'autres agents. Ce sont des instructions toujours actives en texte brut sans chargement conditionnel, donc traitez-le comme la maison d'un petit noyau de faits de projet plutôt que comme un fourre-tout.

Les skills Claude ou les règles Cursor sont-ils meilleurs pour une équipe ? Les skills se versionnent dans git sous .claude/skills/ comme du code, et les règles se versionnent sous .cursor/rules/ de la même façon, donc les deux se distribuent bien. La vraie question d'équipe porte sur la surface : si tout le monde vit dans Cursor, les règles les atteignent sans aucune configuration. Si l'équipe utilise aussi Claude Code, Desktop, ou des agents construits sur le SDK, les skills sont le seul format qui couvre toutes les surfaces, et le schéma de synchronisation ci-dessus empêche les deux de diverger.