Claude Skills vs règles & mémoires Windsurf comparés

Windsurf a fait quelque chose qu'aucun autre éditeur IA n'avait pris la peine de faire : il a donné un carnet à son agent et lui a dit de prendre ses propres notes. Des règles que vous écrivez vous-même, très bien, tous les outils en ont désormais. Mais Cascade, l'agent de Windsurf, génère aussi des mémoires de son propre chef, en pleine conversation, sans qu'on le lui demande. Travaillez dans un dépôt pendant une semaine et il construit discrètement un modèle privé de la façon dont vous aimez faire les choses.

Les skills Claude viennent de la philosophie opposée. Rien n'entre dans un skill à moins qu'une personne ne l'ait écrit, et rien ne s'active à moins que la description ne le mérite. Nous faisons tourner SkillProof, où nous installons des skills sur une machine vierge et les testons avant de les référencer, donc nous vivons du côté explicite de cette fracture. Nous allons quand même essayer d'être justes, parce que l'idée d'auto-mémoire mérite mieux qu'un rejet.

En bref : les règles Windsurf forment un solide système d'instructions toujours actif et ciblé par glob, proche de celui de Cursor. Les mémoires sont la partie vraiment nouvelle : une personnalisation à effort zéro qui améliore l'éditeur plus vous l'utilisez. Les skills gagnent sur la portabilité, l'outillage embarqué, le travail qui n'est pas du code, et le fait que vous pouvez lire chaque mot de ce qu'on a appris à votre IA. Si vous vivez entièrement dans Windsurf, utilisez les règles pour les lois strictes et laissez les mémoires s'accumuler, mais auditez-les tous les mois. Si Claude fait partie de votre workflow quelque part, gardez votre expertise durable dans des skills et traitez la mémoire de Windsurf comme un cache, pas comme une source de vérité.

	Règles + mémoires Windsurf	Skills Claude
Format	Markdown dans .windsurf/rules/, plus des mémoires auto-générées par espace de travail	Dossier SKILL.md dans ~/.claude/skills/ ou .claude/skills/
Déclenchement	Always On, glob, Model Decision, ou mention manuelle @ ; les mémoires apparaissent automatiquement	Correspondance de description, décidée par le modèle
Qui l'écrit	Vous écrivez les règles ; Cascade écrit les mémoires	Vous, ou un auteur que vous pouvez vérifier
Contenu	Texte brut, plafonné (environ 6 000 caractères par fichier de règle)	Instructions plus scripts, modèles, fichiers de référence
Portabilité	Windsurf uniquement	Claude Code, Claude Desktop, claude.ai, l'Agent SDK
Vérifiabilité	Les règles oui ; les mémoires seulement si vous ouvrez le panneau et regardez	Tout sur disque, comparable en diff, sous contrôle de version
Culture du test	Aucune	Majoritairement inexistante ; nous testons les nôtres

Ce que sont vraiment les règles et mémoires Windsurf

Windsurf scinde le contexte persistant en deux systèmes que sa documentation regroupe sous un seul nom, Memories, ce qui perturbe tout le monde. Ça vaut le coup de les séparer.

Les règles sont des fichiers markdown que vous écrivez. Les règles de projet vivent dans .windsurf/rules/, un fichier par sujet, et un global_rules.md s'applique à tous les projets. Chaque fichier porte un mode d'activation : Always On (injecté dans chaque requête Cascade), Glob (s'attache quand un fichier correspondant est dans le contexte, donc les règles *.tsx accompagnent le travail React), Model Decision (Cascade lit une description que vous fournissez et décide), et Manual (seulement quand vous le mentionnez avec @). Les fichiers sont plafonnés à environ 6 000 caractères chacun avec un budget combiné entre règles globales et d'espace de travail, donc Windsurf vous dit directement que ce contenu se trouve dans le prompt et que la longueur a un prix.

Si vous avez lu notre comparatif Cursor, ça devrait sonner familier. Les quatre modes correspondent presque un pour un à ceux de Cursor, et l'analyse du déclenchement toujours actif et par glob se transpose sans changement.

Les mémoires sont la partie sans équivalent chez Cursor. Pendant que vous travaillez, Cascade décide que quelque chose vaut la peine d'être retenu, « ce projet utilise pnpm, pas npm », « l'utilisateur préfère les retours anticipés aux conditions imbriquées », et l'enregistre comme une mémoire limitée à l'espace de travail. Vous pouvez aussi lui demander explicitement de retenir quelque chose. Les mémoires persistent entre les sessions, apparaissent automatiquement quand Cascade les juge pertinentes, et ne coûtent aucun crédit à générer. Il existe un panneau où vous pouvez les lire, les modifier et les supprimer, ce qui comptera plus loin.

Donc le cadrage honnête n'est pas skills contre règles. C'est un format d'instructions explicite et portable contre un hybride : des règles explicites plus une couche de mémoire implicite qui s'écrit elle-même.

Là où Windsurf gagne vraiment

Les auto-mémoires sont une vraie innovation, et on le dira franchement. Le problème le plus difficile des fichiers d'instructions IA est que personne ne les écrit. Chaque équipe dit qu'elle documentera ses conventions pour l'agent ; presque aucune ne le fait, et le fichier qui existe a huit mois de retard. Windsurf contourne entièrement la paresse humaine. La connaissance est capturée comme sous-produit du travail, au moment où elle est démontrée. Après quelques semaines, Cascade connaît votre lanceur de tests, votre style d'imports, et ce répertoire maudit que personne ne touche, et vous n'en avez jamais écrit un mot. Comme réponse à « comment cette connaissance est-elle enregistrée, tout court », c'est la meilleure qu'aucun éditeur ait livrée.

La personnalisation sans configuration. Un nouvel utilisateur de Windsurf obtient par défaut un éditeur qui devient progressivement plus intelligent. Un nouvel utilisateur de skills Claude obtient un répertoire vide et une décision à prendre. Nous avons écrit un guide complet des skills en partie parce que le format a une courbe d'apprentissage ; les mémoires n'en ont aucune.

La portée native de l'IDE. Les règles et les mémoires participent à tout ce que fait Windsurf, y compris les éditions inline et les exécutions agentiques de Cascade, sans étape d'installation. Les skills fonctionnent là où Claude fonctionne, ce qui n'inclut pas l'intérieur de l'éditeur d'une autre entreprise.

La précision du glob. Même argument qu'avec Cursor, et il tient toujours : « attacher ces conventions SQL dès qu'un fichier .sql est dans le contexte » est une garantie mécanique. Les skills l'approximent avec le libellé de la description, que le modèle interprète bien mais ne promet pas.

Là où les skills gagnent

La réutilisation inter-projets et inter-surfaces. Un skill dans ~/.claude/skills/ vous suit dans chaque dépôt, et aussi dans Claude Desktop et claude.ai. Votre discipline de débogage s'applique quand vous corrigez un pipeline au travail et quand vous bricolez un projet personnel un dimanche. Les mémoires Windsurf sont limitées à l'espace de travail par conception ; la leçon apprise avec pnpm dans le projet A doit être réapprise dans le projet B. Des règles globales existent mais partagent ce budget de caractères serré.

Le travail qui n'est pas du code. Windsurf est un IDE, et tout son système de contexte suppose que ce sur quoi on travaille est un dépôt. Les skills s'en moquent. Le même format qui apprend à Claude vos conventions de commit lui apprend aussi à structurer une proposition commerciale ou nettoyer un export de tableur. La moitié de notre catalogue n'a rien à voir avec du logiciel.

L'outillage embarqué. Un fichier de règle, plafonné à 6 000 caractères, décrit un comportement. Un dossier de skill le livre. Le skill docx d'Anthropic inclut des scripts Python qui construisent des documents Word plutôt qu'une prose sur comment on pourrait le faire. Le skill skill-creator porte des modèles et un harnais d'évaluation. Un skill de débogage systématique peut garder sa checklist d'escalade dans un fichier de référence qui ne se charge qu'en pleine investigation. La divulgation progressive est ce qui rend ça abordable : cinquante skills installés restent au repos à quelques milliers de tokens de métadonnées, et le matériel lourd reste sur disque jusqu'au moment où il est nécessaire.

Un écosystème que vous pouvez auditer. Un skill, ce sont des fichiers. Vous pouvez lire chaque ligne avant d'installer, comparer en diff après une mise à jour, et le mettre sous contrôle de version à côté du code qu'il gouverne. Quand un coéquipier demande pourquoi l'agent formate les migrations d'une certaine façon, la réponse est un fichier avec un historique git. C'est aussi ce qui rend les skills tiers testables tout court, et pourquoi notre collection de code peut porter des verdicts pass/fail plutôt que des comptes d'étoiles.

Migrer dans les deux sens

Les formats sont assez proches pour que la conversion soit surtout du réétiquetage. Voici une règle de projet Windsurf typique :

---
trigger: model_decision
description: API endpoint conventions for this service
---

- All endpoints live in src/api/, one file per resource
- Validate request bodies with zod schemas from src/schemas/
- Return errors as { error: { code, message } }, never bare strings
- Every new endpoint needs a happy-path test and a 401 test

En tant que skill, les métadonnées de déclenchement passent dans un frontmatter que Claude fait correspondre, et vous gagnez de la place pour grandir :

---
name: api-endpoint-conventions
description: Conventions for building or modifying API endpoints in this
  service. Use when creating routes, changing request/response shapes, or
  reviewing API code.
---

## Structure
All endpoints live in src/api/, one file per resource.
Validate request bodies with zod schemas from src/schemas/.

## Errors
Return errors as { error: { code, message } }, never bare strings.

## Tests
Every new endpoint needs a happy-path test and a 401 test.
See reference/error-codes.md for the full error catalog.

Enregistrez-le sous .claude/skills/api-endpoint-conventions/SKILL.md. La description fait le travail qu'un mode de déclenchement faisait, donc écrivez-la comme nous le décrivons dans notre guide de déclenchement : nommez la tâche, nommez le moment. Et maintenant le catalogue d'erreurs peut être un fichier de référence embarqué au lieu d'une victime du plafond de caractères.

Dans l'autre sens, prenez le corps d'un skill, réduisez-le sous 6 000 caractères, et choisissez le mode d'activation honnête :

---
trigger: glob
globs: "**/*.test.ts"
---

- Use vitest, never jest
- One describe block per exported function
- No snapshot tests for logic; snapshots are for markup only

Ce que vous perdez dans cet export : les scripts embarqués (les règles ne peuvent pas livrer d'exécutables), les fichiers de référence, et tout ce qui dépasse le plafond. Ce que vous gagnez : un attachement par glob qui se déclenche mécaniquement, sans jugement du modèle impliqué. Tout ce que vous avez appris en convertissant le format de Copilot se transpose ici aussi ; ce comparatif couvre l'équivalent d'applyTo.

Les mémoires sont le reste gênant. Il n'y a pas de bouton d'export ; elles vivent dans le stockage propre de Windsurf. Le geste pratique est d'ouvrir le panneau Memories, de lire ce que Cascade a écrit, et de promouvoir à la main les bonnes vers des règles ou des skills. Ce qui nous amène à la partie inconfortable.

Le problème de l'auto-mémoire : personne ne relit ce qu'elle a appris

Voici la mise en garde qui devrait figurer dans chaque article vantant les auto-mémoires, et qui n'apparaît presque nulle part.

Cascade apprend de ce que vous faites, et ce que vous faites inclut vos erreurs. Acceptez un any paresseux un vendredi à 18h et le système de mémoire n'a aucun moyen de savoir que c'était une capitulation plutôt qu'une préférence. Laissez-le vous observer sauter les tests pendant une semaine de correctif urgent et « cet utilisateur n'écrit pas de tests d'abord » est une observation exacte qu'il peut discrètement généraliser. Le système enregistre le comportement démontré. Il ne peut pas distinguer vos standards de votre relâchement, parce qu'il ne voit jamais que le relâchement.

Le problème plus profond est la revue, ou son absence. Chaque autre artefact qui façonne votre base de code passe sous des yeux : le code est relu, les dépendances sont scannées, les configurations vivent dans des pull requests. Les mémoires sont écrites par le modèle, approuvées par personne, et consultées invisiblement. Windsurf vous donne un panneau pour les inspecter, ce qui est vraiment à son crédit, et dans notre expérience, à peu près personne ne l'ouvre. Quand le comportement dérive, la cause est une phrase dans un magasin dont vous avez oublié l'existence.

Les skills se situent à l'autre bout, et c'est la différence philosophique qui vaut la peine d'être choisie, plus que n'importe quelle liste de fonctionnalités. Un skill est délibéré. Quelqu'un a décidé que cette connaissance valait la peine d'être codifiée, l'a écrite, et peut être interrogé sur pourquoi. Elle est vérifiable avant installation, comparable en diff après les mises à jour, attribuable en git pour toujours. Le coût est honnête aussi : explicite veut dire laborieux, et laborieux veut dire moins de choses capturées. Windsurf a parié que capturer tout implicitement bat capturer moins explicitement. Pour le confort de l'éditeur, ce pari paie souvent. Pour tout ce que vous appelleriez des standards d'ingénierie, nous voulons la version avec un auteur.

Si vous utilisez Windsurf, exploitez sa force et gérez son risque : laissez les mémoires s'accumuler, puis programmez un audit mensuel de dix minutes. Supprimez celles qui ont mémorisé votre mauvaise semaine. Promouvez les bonnes en règles, où elles deviennent explicites et visibles. Cette seule habitude convertit le système de mémoire d'une dérive lente en un entonnoir de capture, avec quelque chose comme un skill de gestion de la mémoire qui gère la même discipline côté Claude.

Deux écosystèmes non testés, une seule habitude de test

Les règles partagées et les skills partagés ont la même maladie : la publication sans vérification. GitHub héberge des milliers de fichiers de règles et de skills écrits une fois, étoilés, et jamais exécutés par personne d'autre que l'auteur, si l'auteur les a exécutés du tout. Quand nous avons commencé à installer des skills communautaires sur des machines vierges, environ la moitié échouait dès le premier essai, et rien ne suggère que les fichiers de règles collés s'en tirent mieux. Ils échouent juste plus silencieusement, parce qu'une règle qui n'aide jamais ressemble exactement à une règle qui n'a jamais été lue.

Les auto-mémoires évitent ce problème particulier, étant générées à partir de votre comportement plutôt que téléchargées depuis un inconnu. Un vrai point en leur faveur, avec le même compromis à nouveau : les mémoires n'ont jamais tort sur ce que vous avez fait, seulement sur si vous le vouliez vraiment.

FAQ

Puis-je utiliser des skills Claude dans Windsurf ? Pas nativement. Cascade lit ses propres règles et mémoires, et les skills sont une convention Claude. Les équipes qui utilisent les deux gardent en général un fichier de règles partagé pour les lois universelles du projet et maintiennent des skills pour les sessions Claude Code dans le même dépôt. Une légère duplication, supportable si les deux restent courts.

Les mémoires Windsurf coûtent-elles des crédits ou des tokens ? Générer des mémoires ne consomme aucun crédit. Leur contenu occupe bien de la place dans le prompt quand Cascade les fait apparaître, comme les règles, ce qui est une raison de plus d'élaguer le magasin occasionnellement.

Où vivent les règles Windsurf par rapport aux skills ? Windsurf : .windsurf/rules/ dans le projet, plus un global_rules.md pour tout. Claude : .claude/skills/<nom>/SKILL.md par projet, ~/.claude/skills/ globalement. Les deux sont du markdown brut ; seuls les skills peuvent porter des fichiers additionnels à côté.

Puis-je exporter les mémoires Windsurf vers un skill ? Il n'y a pas d'exportateur. Ouvrez le panneau Memories, copiez les entrées qui valent la peine d'être gardées, et écrivez-les dans un SKILL.md avec une description qui nomme quand elles s'appliquent. Dix minutes de travail, et le résultat est versionné et portable, ce que le magasin de mémoires n'est pas.

Une règle Windsurf en model_decision est-elle la même chose qu'un déclencheur de skill ? Mécaniquement similaires : les deux laissent le modèle lire une description et décider. Les différences sont ce qui se charge ensuite (un fichier texte plafonné contre un dossier avec des ressources) et où la décision peut se produire (à l'intérieur de Windsurf contre partout où Claude tourne).

Les deux systèmes essaient de résoudre le même problème depuis des bouts opposés : Windsurf en vous observant, les skills en vous demandant. Observer passe mieux à l'échelle. Demander vieillit mieux. Nous préférerions maintenir dix fichiers que nous pouvons lire plutôt que de faire confiance à cent observations que nous n'avons jamais vues, et si ça ressemble au biais professionnel d'un labo de test, c'en est un. C'est aussi comme ça que nous avons attrapé la moitié d'un écosystème qui ne fonctionnait pas.