Claude Code : comment combiner Rules, Skills et Workflow ?

En bref : configurer Claude Code, ce n'est pas empiler des prompts dans un seul fichier. C'est quatre couches distinctes — CLAUDE.md pour les faits projet toujours utiles, Rules pour les contraintes dures et les conventions par chemin, Skills pour les procédures multi-étapes réutilisables, et Workflow pour enchaîner Skills, Hooks, tâches planifiées et CI en rythme d'équipe. L'erreur la plus fréquente : mélanger les couches. Une checklist de déploiement de quarante lignes dans CLAUDE.md consomme des milliers de tokens à chaque session ; une interdiction de force push enfouie dans un Skill disparaît après compaction du contexte.

Ce guide s'adresse aux développeurs iOS, Flutter et applications IA qui utilisent ou évaluent Claude Code — en particulier les équipes qui envisagent de déplacer le développement principal vers un Mac cloud ou une location de Mac distant. Nous nous appuyons sur la documentation officielle et des tests terrain en août 2026 : arborescence .claude, exemples de frontmatter YAML, tableau de décision et points d'attention pour un Mac Apple Silicon en production continue.

Données vérifiées le 6 août 2026. Comportement selon la documentation Skills de Claude Code et le blog de pilotage Anthropic ; les champs frontmatter peuvent varier légèrement selon la version.

Pourquoi des couches plutôt qu'un seul CLAUDE.md géant

Le réflexe de beaucoup d'équipes : Claude Code lit le dépôt, donc tout mettre dans CLAUDE.md à la racine. Le problème, c'est le budget de contexte partagé — plus vous chargez en permanence, moins il reste de place pour les diffs et les sorties d'outils. Pire encore quand procédures (« lancer les tests, bumper la version, tagger, pousser ») et faits (« le scheme principal s'appelle MyApp-Prod, le profil est dans le trousseau XYZ ») cohabitent : une petite modification peut tout faire bouger.

Dans l'article officiel sur le pilotage de Claude Code, Anthropic distingue sept leviers : CLAUDE.md, Rules, Skills, Subagents, Hooks, Output Styles et extensions du prompt système. Pour la plupart des équipes d'ingénierie, les quatre premiers plus l'orchestration Workflow couvrent environ 90 % des besoins. Si vous utilisez déjà la stack Cursor + Claude Code + OpenRouter, la couche terminal peut s'apparenter aux .cursor/rules de l'IDE — mais les chemins et les moments de chargement diffèrent ; un copier-coller direct ne fonctionne pas.

Cas d'échec typique : une équipe Flutter à cinq personnes empile checklist de review, étapes d'archive et politique de branches dans CLAUDE.md jusqu'à dépasser 400 lignes. Claude traîne ce runbook même pour modifier un widget — réponses plus lentes, et après compaction il « oublie » souvent les exigences de test en fin de fichier. Après découpage en Rules scopées par chemin et trois Skills, la consommation moyenne d'entrée a baissé d'environ 30 %, avec moins d'oublis en review.

Concepts clés : le rôle de chaque couche

CLAUDE.md : la mémoire permanente du projet

CLAUDE.md (ou .claude/CLAUDE.md) se charge à chaque ouverture de session. On y met des informations courtes, stables et partagées par toute l'équipe :

• Commandes build et test en une ligne (ex. xcodebuild -scheme MyApp test)
• Carte du monorepo (apps/ios, packages/core — qui fait quoi)
• Index des Skills et Rules actifs (une ligne de description + chemin)
• Résumés des interdits d'équipe (le détail va dans les Rules)

La recommandation officielle : rester concis ; au-delà de 200 lignes, vérifiez si des procédures se sont glissées par erreur. CLAUDE.md n'est pas un wiki interne, c'est la checklist de démarrage de Claude.

Rules : contraintes et conventions par chemin

Les Rules sont des fichiers Markdown dans .claude/rules/. Par rapport à CLAUDE.md :

• Elles peuvent être scopées par chemin — chargées seulement quand vous éditez des fichiers correspondants (ex. paths: ["**/*.swift"])
• Elles sont réinjectées après compaction du contexte — idéal pour les lignes rouges de sécurité
• Le ton est impératif (« doit / interdit »), pas « voici douze suggestions »

Contenu typique : interdiction de committer des secrets, conventions de nommage Swift, migrations DB obligatoirement réversibles, l'agent ne doit pas exécuter git push --force. Dans notre checklist de sécurité des agents IA sur Mac distant (Black Hat USA 2026), nous insistons : les limites d'un agent terminal doivent être écrites en Rules auditables, pas transmises à l'oral.

Skills : playbooks réutilisables

Les Skills vivent dans ~/.claude/skills/ (utilisateur) ou .claude/skills/ (projet). Chaque Skill est un dossier centré sur SKILL.md. Selon la documentation officielle, ils suivent une divulgation progressive :

• Au démarrage : seuls name et description sont chargés
• À l'appel : le texte complet et les scripts associés
• Plusieurs Skills partagent un budget token ; les premiers appelés peuvent être évincés

Bons candidats Skill : checklist de release TestFlight, étapes de PR review, remplacement batch i18n Flutter, régénération client OpenAPI. Le frontmatter YAML peut définir allowed-tools (outils pré-autorisés), disable-model-invocation: true (déclenchement manuel /nom-skill uniquement) ou context: fork (exécution dans un sous-agent).

Workflow : relier les pièces au rythme de l'équipe

Workflow n'est pas un cinquième dossier : c'est qui déclenche quoi, et quand. Un Hook formate avant git commit ; launchd appelle /refactor-module la nuit ; la CI lance Claude Code en mode non interactif pour une migration ; un Mac cloud conserve la même arborescence .claude via Git. Le Workflow répond à la question : « à quel moment automatise-t-on quelle couche ? »

Tableau de combinaison : quoi mettre où

Mise en pratique : configurer une équipe iOS de zéro

Cette structure fonctionne dans des dépôts iOS / Flutter mixtes de 2 à 6 personnes — à adapter selon votre contexte :

your-repo/
├── CLAUDE.md                    # commandes build, schemes, index Skills
├── .claude/
│   ├── settings.json            # réglages équipe (pas de secrets)
│   ├── settings.local.json      # surcharge locale, gitignore
│   ├── rules/
│   │   ├── global-security.md   # pas de .env, pas de force push
│   │   ├── ios-swift.md         # paths: ["**/*.swift"]
│   │   └── flutter-dart.md      # paths: ["lib/**/*.dart"]
│   └── skills/
│       ├── release-testflight/
│       │   └── SKILL.md
│       └── pr-review/
│           └── SKILL.md

Étape 1 : rédiger CLAUDE.md (80 à 120 lignes). En tête, un tableau des schemes, version iOS minimale et entrée des tests ; au milieu, la carte des répertoires ; en bas, la liste des Skills disponibles (nom + une phrase). Pas de procédure pas à pas ici.

Étape 2 : découper les Rules. Règles de sécurité globales dans un fichier dédié ; conventions linguistiques par chemin. Exemple de frontmatter scopé :

---
paths:
  - "**/*.swift"
  - "**/*.xcodeproj/**"
---

# Contraintes iOS / Swift
- Toute nouvelle UI doit avoir une Preview ou une justification d'absence
- Ne pas modifier le Team ID dans Signing & Capabilities
- Toute modification réseau doit mettre à jour les tests unitaires correspondants

Étape 3 : créer le premier Skill. Commencez par le flux le plus fréquent et le plus risqué — souvent release TestFlight ou review de PR :

---
name: release-testflight
description: "Archiver le scheme principal et envoyer sur TestFlight ; jour de release ou quand l'utilisateur dit « release »"
disable-model-invocation: true
allowed-tools: Bash(xcodebuild *) Bash(fastlane *)
---

## Vérifications avant release
1. Confirmer que `main` est mergé et CI verte
2. Vérifier cohérence CHANGELOG et numéro de version
3. Lancer `xcodebuild -scheme MyApp -destination 'generic/platform=iOS' archive`
4. Appeler fastlane `upload_testflight`
5. Commenter le numéro de build sur la PR

disable-model-invocation: true signifie que seul un /release-testflight manuel charge le Skill — Claude ne déclenchera pas un release en modifiant une UI. Indispensable pour les opérations sensibles.

Étape 4 : brancher le Workflow. Dans .claude/settings.json, configurez les Hooks (ex. PreToolUse pour bloquer les commandes dangereuses). Le même dossier .claude sur Mac cloud et en local — le comportement SSH sur Mac distant reste identique. Config d'équipe via Git ; clés API et settings.local.json en gitignore.

Mac cloud / Apple Silicon : où ça compte au quotidien

Claude Code est un agent terminal — la qualité de l'environnement d'exécution détermine jusqu'où vous lui faites confiance. Dans un scénario Mac cloud ou location de Mac distant VPSSpark, une config en couches apporte trois bénéfices concrets :

• Environnement figé : .claude/, dépendances Homebrew et version fastlane dans l'image — nouveau nœud, pas de réinstallation des Skills.
• Sessions longues plus stables : mémoire unifiée Apple Silicon M4 pour Xcode, simulateur et Claude Code en parallèle ; veille ~4 W — adapté aux Skills nocturnes /refactor.
• Isolation des droits : utilisateur système dédié pour l'agent sur le Mac cloud ; Rules limitant l'accès au trousseau — plus sûr que sur la machine personnelle.

Workflow type : code dans Cursor en local → push Git → CI sur Mac cloud tire le dépôt et exécute un Skill de migration en non interactif → upload fastlane. Les Rules empêchent le force push en CI ; les Skills alignent les étapes sur un release manuel. Les équipes Flutter peuvent skilliser flutter build ipa et la signature iOS avec les mêmes Rules de sécurité.

Avec OpenRouter pour réduire les coûts API, allowed-tools et le choix de modèle restent indépendants — mais surveillez la mémoire quand des sous-agents (context: fork) tournent en parallèle : un M4 16 Go avec deux Skills fork + Archive Xcode peut saturer. Prévoyez dans une Rule ou un Skill : « pas de second fork pendant Archive ».

Coûts, performance et risques

Coût tokens : un CLAUDE.md gonflé paie une « taxe de fond » à chaque session ; les Skills économisent grâce à la divulgation progressive — mais plusieurs Skills dans une même session se partagent le budget. Utilisez régulièrement /context ou les stats officielles pour voir quelle couche domine.

Coût de maintenance : Rules et Skills sont reviewables et versionnables — moins cher que les consignes orales ; au-delà de quinze Skills, désignez un responsable d'index, sinon les nouveaux ne trouvent pas le bon Skill.

Risques : allowed-tools réduit les confirmations pendant l'activation du Skill — à réserver aux Skills de confiance. Sur nœud Mac cloud partagé, isolez les clés personnelles dans settings.local.json. Un Hook mal configuré peut bloquer les commits — testez d'abord sur une branche.

Par rapport à « ne rien configurer et tout réexpliquer à chaque fois », 2 à 4 heures de mise en place se rentabilisent souvent dès la troisième semaine. Par rapport à « tout dans CLAUDE.md », la facture tokens et le taux d'oubli restent maîtrisables sur la durée.

FAQ

Les Rules Claude Code et les Cursor Rules sont-elles interchangeables ?

Le concept est proche, pas les chemins ni le format. Cursor utilise .cursor/rules, Claude Code .claude/rules/. Vous pouvez maintenir une source Markdown commune et la synchroniser par script — pas d'interopérabilité automatique.

Un Skill peut-il appeler des scripts externes ?

Oui. Placez-les dans scripts/ du dossier Skill ; avec allowed-tools: Bash(./scripts/*) pour limiter les confirmations. Les scripts méritent une review comme du code de production — pas de shell non audité exécuté par l'agent.

Comment l'équipe valide-t-elle une nouvelle Rule ou Skill ?

Dans le même PR que le code : toute nouvelle .claude/rules/foo.md ou skills/bar/SKILL.md exige un reviewer humain pour conflits avec les Rules de sécurité et doublons dans CLAUDE.md. La documentation Settings décrit skillOverrides pour désactiver temporairement sans supprimer.

Claude oublie les étapes d'un Skill après compaction ?

Les Skills appelés tôt peuvent sortir du budget partagé. Contre-mesures : étapes critiques en Hook ; Skill qui termine par une checklist écrite dans un fichier ; Skills de release avec disable-model-invocation: true et sessions courtes.

Ça vaut le coup en solo ?

Oui, en version minimale : 50 lignes de CLAUDE.md, deux Rules (sécurité + langage), un Skill pour la tâche la plus fréquente (ex. /ship). Avantage solo : itération rapide — 15 minutes par semaine valent mieux que retaper les commandes build à chaque session.

Conclusion : cartographier le workflow avant d'écrire les fichiers

Combiner Rules, Skills et Workflow dans Claude Code, c'est découper l'expérience humaine en modules chargeables par la machine. CLAUDE.md répond à « quel est ce projet », les Rules à « qu'est-ce qui est interdit », les Skills à « comment exécuter le flux complexe », le Workflow à « quand automatiser ». Clarifier les quatre couches avant d'écrire cinq cents lignes de prompt, c'est nettement plus serein.

Ordre de déploiement conseillé : cette semaine le squelette CLAUDE.md → la semaine prochaine deux Rules de sécurité → ensuite le Skill le plus fréquent → enfin un Hook sur Mac cloud ou CI. Mesurez tokens et oublis à chaque couche ajoutée sur une vraie tâche.