Everything Claude Code (ECC) : le framework d’agents open source pour Claude Code

Depuis l’essor des agents de code, combien de fois avez-vous dû réexpliquer votre stack, vos conventions, vos préférences et vos critères de revue au démarrage de chaque session ?

Le problème, c’est que chaque nouvelle conversation commence à froid. Des outils comme Claude Code savent écrire du code, mais ils ne savent pas comment votre équipe écrit du code. Ce qui devait faire gagner du temps se transforme en copier-coller manuel du même contexte projet, en corrections quand le modèle dérive, en optimisation des consignes, et en relecture des mêmes suggestions génériques, encore et encore.

Everything Claude Code (ECC) est un framework open source conçu pour corriger cela. Malgré son nom, il n’est pas affilié à Anthropic. C’est un système d’agents et une couche de workflows qui se superposent à Claude Code (ce n’est ni un modèle, ni un IDE) et transforment un agent de code générique en une plateforme d’ingénierie spécialisée qui connaît déjà vos standards.

Dans cet article, nous verrons ce qu’est ECC, comment ses composants s’articulent, comment l’installer, et pour qui il est réellement utile.

Mais au fait, qu’est-ce que Claude Code exactement ? Inscrivez-vous à notre cours Claude Code 101 pour apprendre à l’utiliser dans vos workflows de développement au quotidien.

Qu’est-ce que Everything Claude Code ?

ECC est un dépôt open source qui enveloppe Claude Code d’une couche opératoire prête à l’emploi pour les travaux d’ingénierie.

Le projet est disponible sur affaan-m/ECC sur GitHub. Sous licence MIT, il est maintenu par Affaan Mustafa, et résulte de plus de 10 mois d’usage quotidien de Claude Code sur des produits réels. Il n’est pas affilié à Anthropic, malgré le nom.

Le dépôt regroupe quatre éléments en une seule installation :

• Un harnais d’agents : un ensemble de sous‑agents spécialisés (planificateur, architecte, relecteur de code, auditeur sécurité, résolveur d’erreurs de build, et bien d’autres) auxquels Claude Code délègue au lieu d’essayer de tout faire dans une seule fenêtre de contexte.
• Un écosystème de compétences : quelques centaines de petits workflows couvrant le TDD, les revues sécurité, les patterns de frameworks (Django, Spring Boot, Next.js, etc.), des standards de code par langage, et des tâches de MLOps/ingénierie ML.
• Un framework de workflows : des hooks déclenchés par des événements d’outils, des règles toujours actives, des configurations de serveurs MCP, et une mémoire de session qui persiste d’une conversation à l’autre.
• Une couche de commandes : des entrées slash maintenues pour exécuter les workflows courants, plus un dossier de compatibilité pour les anciens noms de commandes.

Il est important de rappeler que Claude Code reste le moteur. C’est lui qui lit le code et exécute les outils.

Le rôle d’ECC, c’est tout ce qu’il y a autour : indiquer à Claude Code quel sous‑agent doit gérer la tâche, quelles étapes de workflow suivre, quelles conventions s’appliquent à votre stack, et quel contexte reprendre de la session d’hier.

Concrètement, vous n’avez plus à configurer Claude Code à partir de zéro pour chaque projet. Vous installez ECC une fois, copiez les packs de règles adaptés à votre stack, et vous disposez d’une plateforme d’ingénierie spécialisée qui sait déjà comment procéder.

Pourquoi Everything Claude Code est devenu si populaire

La dynamique est partie d’un fil sur X.

Début 2026, Mustafa a publié The Shorthand Guide to Everything Claude Code. Le post a dépassé les 10 000 favoris en quelques jours. Puis il a ouvert le dépôt, et ECC a désormais franchi 200 000 étoiles et plus de 34 forks.

Voici pourquoi :

• Le codage « agentique » est passé de l’expérimentation à l’usage quotidien : à mesure que des développeurs adoptaient Claude Code, les limites du système par défaut apparaissaient. Ce dont ils avaient besoin, c’était d’une couche de configuration prête à l’emploi éliminant le démarrage à froid, les revues de code incohérentes, et autres…
• Rédiger de bons prompts d’agents est plus difficile qu’il n’y paraît : un workflow TDD solide ou un prompt de relecteur filtrant par confiance exigent des itérations. Beaucoup d’équipes ne veulent ni construire ni maintenir cela au fil des évolutions de modèles : réutiliser une version éprouvée est plus simple.
• Les contributions se sont accumulées : plus de 270 contributeurs ont ajouté des packs de règles (Java, Kotlin, Rust, Perl, PHP), la prise en charge de frameworks (Quarkus, Laravel), des traductions, des intégrations IDE au‑delà de Claude Code (Cursor, OpenCode, Zed), et des compétences.
• ECC apporte la spécialisation sans fine-tuning : entraîner un modèle sur les conventions d’équipe est peu réaliste pour la plupart. Un ensemble structuré de compétences et d’agents à l’exécution s’en rapproche, et ECC fait partie des tentatives les plus abouties pour emballer cela.

Bref, ça a commencé sur X, puis l’effet boule de neige a pris.

Comment fonctionne Everything Claude Code

ECC est un système en couches.

Cinq composants se trouvent entre vous et votre base de code. Claude Code est l’exécution. Les compétences, les agents, MCP et une couche mémoire l’enveloppent. Chaque pièce a un rôle, et elles se passent le relais durant la session.

Claude Code

Claude Code est l’interface du modèle sous-jacente.

C’est le CLI officiel d’Anthropic pour exécuter Claude comme agent de code. Il lit des fichiers, écrit des diffs, lance des commandes shell, appelle des outils et tient la conversation. ECC ne remplace rien de tout cela. Tout ce qu’ajoute ECC est chargé dans Claude Code au démarrage de la session et s’exécute via son système de plugins, hooks et commandes.

Compétences

Les compétences sont des modes opératoires réutilisables stockés en Markdown.

Chaque compétence est un petit dossier avec un SKILL.md qui indique à Claude Code comment traiter un type de tâche précis. La compétence décrit l’objectif, les étapes, la sortie attendue et les contraintes. ECC en regroupe environ 260 couvrant des patterns de langage, des workflows de test, des conventions de frameworks, l’ingénierie ML et des tâches opérationnelles.

À retenir : vous n’exécutez pas les compétences manuellement. Claude Code les sélectionne selon ce que vous faites, ou vous les mentionnez dans un prompt.

Agents

Les agents sont des sous‑agents spécialisés auxquels Claude Code délègue.

Chacun est défini en Markdown avec un nom, une description, une liste d’outils autorisés et un prompt système cadrant son comportement. L’agent code-reviewer ne fait que lire des fichiers et reporter ses constats. Le planner rédige un plan d’implémentation avant de toucher au code. Vous voyez l’idée.

L’objectif de cette séparation, c’est l’isolation du contexte. Chaque sous‑agent dispose d’une fenêtre de contexte propre à sa tâche, évitant d’encombrer la session principale. L’agent principal coordonne, les sous‑agents exécutent.

Intégrations MCP

MCP (Model Context Protocol) est la façon dont Claude Code communique avec des outils et sources de données externes.

ECC fournit des configurations pour se connecter à GitHub, Supabase, Vercel, Railway, et d’autres via des serveurs MCP. Chaque serveur expose des outils que Claude Code peut appeler au fil de la session. ECC livre des configs fonctionnelles et des règles de sécurité pour ces serveurs.

Par défaut, ECC active un seul connecteur (chrome-devtools). Tout le reste est opt‑in, ce qui évite les collisions de noms d’outils et réduit la surface d’attaque.

Couche mémoire

La couche mémoire rend ECC « étatful » d’une session à l’autre.

Des hooks s’exécutent à l’événement Stop de chaque conversation et écrivent un résumé de session dans ~/.claude/sessions/. La session suivante charge le contexte pertinent au démarrage via un hook SessionStart. Les compétences que le modèle « apprend » de vos habitudes sont extraites dans le système Continuous Learning v2, stockées comme des instincts avec un score de confiance, réutilisables ensuite.

Les alias de session, compétences apprises et métriques vivent sous une racine de données unique (par défaut ~/.claude, configurable par harnais si vous exécutez ECC à la fois dans Claude Code et Cursor).

Comment les pièces coopèrent

Une session typique ressemble à ceci :

1. Démarrage de session : un hook charge le contexte de la session précédente, plus les compétences et règles pertinentes pour le projet courant.
2. Vous demandez quelque chose : par exemple « ajouter la connexion OAuth ».
3. Le planificateur s’exécute en premier : il rédige un blueprint, sans écrire de code.
4. La compétence TDD intervient : Claude Code suit le workflow « test rouge, implémentation minimale, refactor ».
5. Les outils MCP sont appelés : par exemple le MCP GitHub récupère des PR liées, ou le MCP Supabase vérifie le schéma.
6. L’agent de revue de code s’exécute à la fin : il audite le diff dans sa propre fenêtre de contexte et remonte ses constats.
7. Fin de session : un hook Stop écrit un résumé, extrait les nouveaux motifs en instincts, et les stocke pour la prochaine fois.

Le modèle reste Claude Code. ECC orchestre simplement quelle compétence, quel agent et quel outil utiliser à chaque étape.

Les compétences dans Everything Claude Code

Les compétences sont le moyen principal par lequel ECC indique à Claude Code quoi faire.

Une compétence est un dossier avec un fichier SKILL.md. Le Markdown définit l’objectif, les étapes, les contraintes, la sortie attendue et les contextes d’application. C’est un simple fichier texte que le modèle lit à l’exécution.

Et c’est voulu. ECC ne « réentraîne » rien : il charge des consignes que Claude lit et suit à la volée.

Les compétences se trouvent dans le dossier skills/ à la racine du dépôt. Après installation, elles sont copiées dans ~/.claude/skills/. Claude Code les charge comme enfants directs de ce dossier.

Chaque dossier de compétence a une structure de base identique :

• SKILL.md - la définition du workflow
• Fichiers d’appui optionnels (modèles, scripts, exemples)
• Un metadata.yaml facultatif pour l’étiquetage et la découverte

Les compétences influencent le comportement des agents de deux manières. D’abord, Claude Code les lit au démarrage et les garde en référence. Ensuite, le modèle choisit la compétence pertinente selon votre demande. Si vous dites « écris d’abord un test en échec », la compétence TDD s’active. Si vous dites « vérifie ça pour des injections SQL », la compétence d’audit sécurité s’active.

ECC est livré avec environ 260 compétences. En voici quelques‑unes pour illustrer l’étendue :

• frontend-patterns : conventions React et Next.js. Structure des composants, usage des hooks, arbitrage serveur vs. client components, motifs de gestion d’état.

• django-patterns, django-tdd, django-security, django-verification : une stack Django complète décomposée en quatre compétences. Une pour l’architecture, une pour le cycle de tests, une pour un audit type OWASP, une pour la boucle « vérifier avant de livrer ».

• architect (pairée avec l’agent architect) : revues de conception système. La compétence définit la couverture d’une revue d’architecture, les livrables produits et les arbitrages à exposer.

• tdd-workflow : le cycle rouge‑vert‑refactor. Écrire le test en échec, écrire le minimum pour le faire passer, refactorer, vérifier la couverture. La compétence impose l’ordre.

• security-review : checklist OWASP Top 10, détection d’identifiants en dur, validation des entrées, vérification des vulnérabilités de dépendances. La compétence définit quoi scanner et quoi signaler.

Les agents dans Everything Claude Code

Les agents sont des « personas » spécialisés avec leur propre fenêtre de contexte.

Chacun est un fichier Markdown dans le dossier agents/ avec un nom, une description, une liste d’outils autorisés et un prompt système. Le prompt système définit la mission de l’agent. La liste d’outils autorisés contrôle ce qu’il peut faire (lire des fichiers, exécuter bash, appeler des serveurs MCP, écrire du code). Claude Code lui délègue automatiquement des tâches.

ECC comprend 66 agents, regroupés en quelques catégories.

Agents de planification exécutés avant toute écriture de code.

L’agent planner décompose une demande de fonctionnalité en blueprint d’implémentation : fichiers à modifier, interfaces à définir, tests à écrire, cas limites à traiter. L’agent architect prend de la hauteur : conception système, modèle de données, frontières de services. Ces agents ne font que lire le code et rédiger des plans.

Agents de codage pour l’implémentation.

Le tdd-guide impose le test‑first. Des résolveurs spécifiques par langage comme go-build-resolver, pytorch-build-resolver et kotlin-build-resolver corrigent les erreurs de build dans leurs écosystèmes. Le refactor-cleaner supprime le code inutilisé.

Agents d’architecture pour les décisions structurelles.

L’architect couvre la conception, le database-reviewer les patterns de requêtes et les choix de schéma, et le mle-reviewer audite les pipelines ML en production (contrats de données, couverture d’évaluation, serving, monitoring).

Agents QA pour vérifier ce qui a été construit.

Le code-reviewer audite les diffs en qualité et sécurité avec un seuil de confiance. Le security-reviewer exécute un passage façon OWASP. L’e2e-runner gère les tests de bout en bout avec Playwright. Des relecteurs par langage (typescript-reviewer, python-reviewer, go-reviewer, rust-reviewer, etc.) assurent les contrôles spécifiques.

La raison de cette séparation : l’isolation du contexte.

Quand le code-reviewer tourne, il obtient une fenêtre de contexte neuve avec uniquement le diff et la compétence de revue chargés. Il ne voit ni les notes de planification ni l’historique. Il fait juste sa revue. Cette focalisation produit de meilleurs résultats que de demander à un agent généraliste de planifier, coder, tester et relire dans le même contexte, comme le font la plupart des setups Claude Code improvisés.

Gestion du contexte et de la mémoire dans ECC

Contrairement à Claude Code, ECC ne perd pas tout entre les sessions.

La mémoire dans ECC est un système de hooks qui écrivent des fichiers aux bons moments et les rechargent au bon moment. Ce ne sont que des fichiers Markdown et JSON sur disque.

Trois éléments persistent :

1. Les résumés de session sont écrits à la fin : un hook Stop s’exécute après le dernier message, prend la transcription complète, et écrit un résumé dans ~/.claude/sessions/. Le résumé couvre ce qui a été fait, décidé, et ce qui reste ouvert. La session suivante le lit via un hook SessionStart pour reprendre là où vous en étiez.
2. Les instincts sont des motifs extraits de vos sessions : le système Continuous Learning v2 observe ce que vous faites et ce qui fonctionne, puis écrit des instincts individuels avec un score de confiance, une action, des preuves et des exemples. Exécutez /instinct-status pour voir ce qui a été appris. Exécutez /evolve pour regrouper des instincts liés en une nouvelle compétence.
3. Des logs tracent la couche opérationnelle : exécutions de hooks, activations de compétences, appels MCP, coûts, erreurs. Stockés sous ~/.claude/metrics/ et ~/.claude/session-data/. Pratique pour le debug et pour le tableau de bord GUI fourni avec le dépôt.

Si cela ne vous paraît pas déterminant, voici deux ou trois raisons qui vous feront changer d’avis :

• Projets au long cours : un refactoring sur six mois ne repart pas de zéro chaque lundi. Les décisions, arbitrages et points connus de la semaine passée sont dans le résumé chargé au démarrage.
• Plus d’explications répétées : vous ne recollez plus votre stack, vos conventions, ni « rappelez‑vous, nous avons choisi Postgres, pas Oracle » à chaque fois.
• Contourner les limites de fenêtre de contexte : même avec un million de tokens, vous ne ferez pas tenir six mois d’historique. Les résumés compressent l’essentiel. L’historique complet reste sur disque, le modèle ne charge que le pertinent.

Vous pouvez ajuster le contexte chargé avec des variables d’environnement. ECC_SESSION_START_MAX_CHARS limite la taille du résumé au démarrage (8 000 caractères par défaut). ECC_SESSION_START_CONTEXT=off le désactive pour des setups à faible contexte. ECC_SESSION_RETENTION_DAYS contrôle la durée de rétention avant purge.

Si vous exécutez ECC dans Claude Code et Cursor sur la même machine, définissez ECC_AGENT_DATA_HOME pour séparer leurs mémoires. Sinon, ils écraseront mutuellement leurs fichiers de session.

Prise en charge MCP dans Everything Claude Code

MCP est la voie d’appel de Claude Code pour tout ce qui n’est ni fichier ni commande shell.

Le Model Context Protocol est le standard d’Anthropic pour connecter les modèles à des outils externes. Un serveur MCP s’exécute comme un processus séparé et expose des opérations typées : « lire cette page Notion » ou « ouvrir une PR sur GitHub ». Claude Code les appelle comme des fonctions.

ECC inclut des configs MCP dans mcp-configs/mcp-servers.json pour les services courants : GitHub, Supabase, Vercel, Railway, Linear, etc. Chaque entrée comprend la commande de démarrage, les variables d’environnement nécessaires et les règles de sécurité appliquées par ECC.

À noter : ECC ne les active pas automatiquement.

La politique MCP de juin 2026 a réduit les serveurs activés par défaut à un seul (chrome-devtools). Tout le reste est opt‑in. Vous copiez l’entrée dans le .mcp.json de votre projet, ou vous l’activez via la commande /mcp de Claude Code. Le motif est à la fois pratique (des noms d’outils MCP trop longs cassent certains gateways) et sécuritaire (chaque serveur MCP est une surface d’attaque potentielle).

Concrètement, cela donne :

• Intégrations externes : déposez l’entrée GitHub dans .mcp.json, fournissez un token, et Claude Code peut lire des issues, ouvrir des PR et vérifier le statut CI sans copier‑coller.
• Appels d’outils : les compétences et agents référencent des outils MCP par nom. Par exemple, une compétence de déploiement peut appeler le MCP Vercel, et un agent de revue base de données le MCP Supabase.
• Automatisation projet : vous pouvez combiner des serveurs MCP avec des hooks pour obtenir une automatisation persistante d’une session à l’autre. Un hook « PR ouverte » peut déclencher un agent de revue utilisant MCP GitHub pour récupérer le diff et MCP Linear pour mettre à jour le ticket.

Si vous exécutez déjà vos propres copies des MCP fournis par ECC, définissez ECC_DISABLED_MCPS avec une liste séparée par des virgules. ECC ignorera ces serveurs lors de l’installation et de la synchronisation pour éviter les doublons en conflit sur le même nom.

AgentShield et fonctionnalités de sécurité

La sécurité est l’un des principaux différenciateurs d’ECC.

AgentShield est un auditeur de sécurité autonome fourni avec ECC. Il analyse les configurations Claude Code pour y détecter vulnérabilités, mauvaises configurations, erreurs et risques d’injection. Il s’exécute comme un package npm séparé (ecc-agentshield), mais il est relié à ECC via la compétence /security-scan afin que vous puissiez le lancer depuis une session Claude Code.

Le scan couvre cinq catégories :

• Détection de secrets : 14 motifs pour repérer identifiants en dur, clés API, tokens.
• Audit des permissions : outils et chemins accessibles par chaque agent et compétence, et si ces droits sont trop larges.
• Analyse d’injection via hooks : vérifier si des hooks peuvent être exploités pour exécuter des commandes arbitraires.
• Profilage de risque des serveurs MCP : lecture, écriture ou appels possibles par chaque serveur MCP connecté, et les expositions créées.
• Revue de configuration d’agents : vecteurs d’injection de prompt, autorisations trop larges, contraintes manquantes.

Vous pouvez l’exécuter avec cette commande, sans installation préalable :

npx ecc-agentshield scan

La sortie est une note (de A à F) plus une liste de constats, triés par sévérité. Les constats critiques renvoient le code 2.

Quelques options utiles :

• -fix applique des corrections automatiques pour les problèmes sûrs (suppression de secrets exposés, resserrement de permissions trop larges…)
• -opus exécute le scan via trois agents Claude Opus 4.X dans un pipeline red‑team / blue‑team / auditeur. L’attaquant cherche des chaînes d’exploit. Le défenseur évalue les protections. L’auditeur synthétise le tout en un rapport de risques priorisé.
• -stream diffuse l’analyse en direct, utile sur des configs lentes.

L’approche par pipeline Opus distingue AgentShield d’un simple linter. Des agents adversariaux tentent de chaîner des composants individuellement « OK » en un ensemble exploitable — là où se situent la plupart des attaques d’agents réelles.

AgentShield annonce 102 règles d’analyse statique et 1 282 tests internes à 98 % de couverture, d’après le dépôt. Les chiffres sont à vérifier selon la dernière release, mais on voit clairement que ce n’est pas un script de 50 lignes.

Les formats de sortie incluent le terminal (avec code couleur), JSON (pour la CI), Markdown et HTML. Un GitHub Action et une application GitHub ECC Tools exécutent aussi AgentShield sur les PR.

Pour la plupart des équipes qui utilisent Claude Code en production, AgentShield est la raison la plus concrète d’installer ECC, même sans le reste du framework.

Installer Everything Claude Code

ECC propose deux voies d’installation.

L’erreur la plus fréquente consiste à empiler l’installation via plugin au‑dessus de l’installation manuelle. Les deux copient les mêmes fichiers aux mêmes emplacements, et vous vous retrouvez avec des doublons. Donc : choisissez une seule voie.

Avant d’installer, vérifiez que Claude Code est en v2.1.0 ou ultérieure :

claude --version

Version de Claude

Installation via le gestionnaire de plugins

C’est la voie recommandée pour la plupart des utilisateurs.

Depuis Claude Code, exécutez :

/plugin marketplace add https://github.com/affaan-m/ECC
/plugin install ecc@ecc

Installation du plugin

La première commande enregistre le dépôt ECC comme marketplace. La seconde installe le plugin.

Attention : le système de plugins ne distribue pas les règles. Les règles sont les lignes directrices toujours actives (style de code, workflow Git, standards de test, patterns spécifiques à un langage), et la spécification de plugin de Claude Code ne les inclut pas. Vous les copiez manuellement après l’installation du plugin.

git clone https://github.com/affaan-m/ECC.git
cd ECC
mkdir -p ~/.claude/rules/ecc
cp -r rules/common ~/.claude/rules/ecc/
cp -r rules/python ~/.claude/rules/ecc/

Copiez rules/common plus un pack de langage que vous utilisez réellement. Dans l’exemple ci‑dessus, j’ai copié les règles Python. Ne copiez pas tout : plus de règles signifie plus de contexte chargé à chaque session, souvent inutile pour votre projet.

Installation via fichiers de configuration

Préférez cette approche si vous voulez un contrôle total, ou si l’installation via plugin ne fonctionne pas dans votre environnement.

git clone https://github.com/affaan-m/ECC.git
cd ECC
npm install
./install.sh --profile full

Sous Windows :

.\install.ps1 --profile full
# ou
npx ecc-install --profile full

Cela copie agents, compétences, commandes, hooks et règles dans votre répertoire ~/.claude/. Aucun plugin n’est requis. Tout vit en fichiers que Claude Code lit au démarrage de la session.

Quelques profils utiles à connaître :

• -profile minimal : règles, agents, commandes et compétences cœur uniquement, sans hooks.

• -profile core : l’ensemble par défaut. Hooks inclus.

• -profile full : tout le contenu du dépôt.

Vous pouvez aussi installer des composants ciblés avec --modules ou --with :

./install.sh --target claude --modules hooks-runtime
npx ecc install --profile minimal --target claude --with capability:machine-learning

Si vous hésitez sur les composants adaptés, interrogez l’assistant fourni :

npx ecc consult "security reviews" --target claude

Il renvoie les composants correspondants et les commandes d’installation exactes.

Vérifier l’installation

Vérifiez ce qui a été installé :

/plugin list ecc@ecc

Vérification de l’installation du plugin

Cela affiche les agents, commandes et compétences exposés par le plugin. Pour les installations manuelles, utilisez le wrapper de cycle de vie :

node scripts/ecc.js list-installed
node scripts/ecc.js doctor

doctor détecte fichiers manquants, hooks cassés et incompatibilités de versions. Si quelque chose est signalé, exécutez :

node scripts/ecc.js repair

Pour confirmer que Claude Code voit le nouveau plugin, ouvrez une session et essayez une commande slash :

/ecc:plan "Add user authentication"

Sortie du plan ECC

Pour une installation plugin, le préfixe /ecc: est requis. Pour une installation manuelle, la forme courte (/plan) suffit.

Si quelque chose semble dupliqué ou cassé, n’installez pas par‑dessus. Exécutez d’abord node scripts/uninstall.js --dry-run pour voir ce qui serait supprimé, puis node scripts/uninstall.js pour nettoyer. ECC ne retire que les fichiers qu’il a installés, vos autres configs restent intactes.

Travailler avec les compétences, commandes et workflows

L’essentiel de ce que vous faites dans ECC passe par des compétences plutôt que par des commandes.

La raison : le dossier commands/ est maintenu pour la compatibilité descendante, mais les nouveaux workflows sont développés d’abord dans skills/.

Voici quelques usages qui couvrent la majorité du quotidien.

L’activation des compétences est surtout implicite

Vous n’appelez pas une compétence par son nom en général. Vous décrivez ce que vous voulez, et Claude Code choisit la compétence adaptée. Si vous dites « écris d’abord un test en échec », la compétence tdd-workflow s’active. Le nom de la compétence apparaît dans la réponse pour transparence.

Quand vous voulez être explicite, mentionnez la compétence dans le prompt : « Utilisez la compétence django-tdd pour ajouter le nouvel endpoint. » Ou lancez une commande qui l’encapsule :

/code-review
/security-scan

/ecc:plan "Add OAuth login"

Le préfixe /ecc: est requis pour les installations plugin. Les installations manuelles utilisent la forme courte (/plan, /code-review).

Sortie de la phase de planification ECC

Le ciblage des fichiers fait partie du workflow

La plupart des agents et compétences opèrent sur un périmètre : fichier, dossier, diff, PR. Définissez le périmètre en mentionnant le fichier dans le prompt, en l’ouvrant dans l’éditeur avant l’invocation, ou en passant un chemin à l’agent :

/code-review src/auth/
/python-review services/billing/payment.py

L’agent prend le périmètre, ne charge que les fichiers nécessaires et s’exécute dans sa propre fenêtre de contexte.

L’intégration shell passe par l’outil bash de Claude Code

Les compétences peuvent sortir en shell pour exécuter réellement des tâches : lancer des tests, builder, linter, appeler un CLI. La compétence TDD exécute pytest ou go test. L’agent de correction de build lance le build pour récupérer de vraies erreurs. La compétence security‑scan exécute npx ecc-agentshield scan et parse la sortie.

La compétence définit quelles commandes shell s’exécutent et quand. Des hooks peuvent aussi exécuter des commandes sur des événements d’outils (lancer un typecheck après chaque édition, alerter sur console.log avant un enregistrement).

La gestion MCP est surtout opt‑in

Après installation, ECC n’active qu’un serveur MCP par défaut (chrome-devtools). Pour en ajouter, copiez les entrées de mcp-configs/mcp-servers.json dans le .mcp.json de votre projet, puis activez‑les via la commande /mcp de Claude Code. L’interface /mcp gère activation, désactivation et réauthentification.

Si vous exécutez vos propres serveurs MCP déjà fournis par ECC, définissez :

export ECC_DISABLED_MCPS="github,supabase"

L’installateur et les flux de sync d’ECC les ignoreront, évitant deux serveurs identiques en conflit sur les mêmes noms d’outils.

Les workflows s’enchaînent

Vous n’exécutez pas les compétences une par une isolément. Un scénario typique de fonctionnalité :

/ecc:plan "Add OAuth login with Google"
# l’agent planner rédige un blueprint

# la compétence tdd-workflow s’active pendant l’implémentation
# tests en échec, code écrit, tests au vert

/code-review
# l’agent code-reviewer audite le diff

/security-scan
# AgentShield contrôle le nouveau code et la config

Chaque étape utilise un agent différent dans une fenêtre de contexte fraîche. La session principale coordonne, et le résumé de session capture la chaîne pour la suite.

Everything Claude Code vs frameworks concurrents

ECC n’est pas la seule couche de configuration pour Claude Code. D’autres outils proposent des approches proches avec des compromis différents.

Précisons la catégorie. ECC rivalise avec d’autres frameworks de configuration au‑dessus de Claude Code. Il ne concurrence pas les harnais avec lesquels il cohabite (Cursor, Codex, OpenCode, Zed) ni les plateformes d’agents autonomes (OpenHands, LangGraph, CrewAI), qui sont d’autres catégories.

Trois alternatives reviennent souvent.

BMAD-Method est un framework agile SDLC avec des agents par rôle (Analyste, PM, Architecte, Scrum Master, Développeur, QA). Il fonctionne sur Claude Code, Cursor et Windsurf via npx bmad-method install. Il brille dans la phase amont : transformer une idée en PRD, doc d’architecture et stories découpées avant d’écrire du code. Les outils d’exécution sont plus légers que ceux d’ECC. Pas de scanner sécurité, pas de catalogue MCP. Moins de patterns spécifiques aux langages.

SuperClaude est un framework de config léger basé sur Markdown. Environ 30 commandes slash, 20 agents et quelques modes comportementaux. Installation avec pip install SuperClaude. C’est plus simple qu’ECC par conception : pas de scan sécurité, pas d’orchestrateur. Mais pas non plus de couche mémoire intégrée au‑delà de Claude Code. Si vous voulez un CLAUDE.md efficace avec un set de prompts éprouvés, SuperClaude est un bon choix.

claude-flow / Ruflo (renommé depuis Claude Flow début 2026) est un orchestrateur de swarms multi‑agents. Il applique la méthodologie SPARC (specification, pseudocode, architecture, refinement, completion) et exécute des hiérarchies « reine + 60‑100 agents spécialisés » en parallèle. Mémoire persistante via AgentDB et compatibilité Claude, GPT, Gemini, Ollama. L’infrastructure est plus lourde qu’ECC, pensée pour du parallélisme plutôt que la productivité en session unique.

Pour explorer d’autres options avant de vous décider, awesome-claude-code est un annuaire sélectionné des ressources Claude Code (agents, compétences, plugins, serveurs MCP, configs). C’est là que la communauté découvre l’essentiel.

En résumé : choisissez BMAD pour la planification agile, SuperClaude pour une couche légère, Ruflo pour du multi‑agents parallèle, et ECC si vous voulez une plateforme d’ingénierie complète avec sécurité et mémoire persistante intégrées.

Pour qui Everything Claude Code est‑il fait ?

ECC n’est pas pour tout le monde. Si vous n’utilisez Claude Code que quelques fois par semaine pour de petites tâches, le framework semblera lourd pour peu de bénéfices. Un simple CLAUDE.md d’une centaine de lignes couvrira l’essentiel.

ECC devient pertinent au‑delà de ce seuil.

Voici quand il est mieux adapté que Claude Code « vanille » :

• Ingénieurs IA qui conçoivent des systèmes d’agents : ECC est une référence opérationnelle. Lisez les prompts d’agents, les définitions de compétences, les configs de hooks, et reprenez ce qui marche.
• Passionnés de productivité développeur : si vous soignez vos outils, dotfiles, éditeur, shell, ECC est le même type d’investissement pour Claude Code. Plus vous l’utilisez, plus vous y gagnez.
• Équipes qui utilisent Claude Code au quotidien : si votre équipe l’emploie chaque jour pour la revue, la planification, le refactoring ou la livraison, la cohérence et l’onboarding gagnent un temps précieux. Les nouveaux ont les mêmes agents et workflows.
• Quiconque construit des workflows d’agents complexes : pipelines multi‑étapes, orchestration de sous‑agents, chaînage MCP, contexte persistant, etc. ECC a déjà résolu la plupart de ces problèmes, et les patterns sont réutilisables même sans tout installer.

Et quand éviter ECC :

• Utilisateurs occasionnels de Claude Code : quelques sessions par semaine pour « m’aider à débugger ce script » ne justifient pas 60+ agents, 260+ compétences et une couche mémoire. La mise en place ne vaut pas l’effort.
• Tâches ponctuelles et simples : petits scripts, correctifs mineurs, démos, prototypes jetables. Claude Code seul suffit ; ajouter ECC ajoute de la friction pour peu de valeur.
• Équipes déjà bien équipées : si votre CLAUDE.md est abouti et vos workflows stables, migrer vers ECC demande du temps. Piochez les éléments utiles, laissez le reste.

Si vous hésitez, l’option sûre est de lire le dépôt, copier deux ou trois agents et compétences intéressants, et d’éviter l’installation complète pour l’instant.

Atouts et limites d’ECC

Voici un tour d’horizon des forces et faiblesses d’ECC, utiles avant de décider.

Atouts

• Bibliothèque de compétences très riche : ~260 compétences couvrant TDD, audits sécurité, patterns de frameworks, idiomes de langage, ingénierie ML, déploiement, etc. Même sans installation, le dépôt est une référence pour rédiger de bonnes définitions de compétences.
• Réutilisation de workflows : prompts éprouvés pour revue de code, planification, refactor et tests. L’agent de revue de code est souvent cité, y compris par des utilisateurs n’ayant pas installé ECC mais ayant repris le prompt.
• Mémoire persistante : résumés de sessions et contexte inter‑sessions fonctionnent nativement. La plupart des configs Claude Code n’adressent pas la mémoire.
• Solide support MCP : configs prêtes pour GitHub, Supabase, Vercel, Railway, etc.
• AgentShield : le scanner sécurité à lui seul justifie l’installation d’ECC. Peu d’autres configs Claude Code offrent un équivalent.
• Open source sous MIT : pas de paywall sur le cœur. L’app GitHub hébergée et ECC Pro sont séparés.
• Multi‑plateforme : fonctionne avec Claude Code, Cursor, Codex, OpenCode, Zed, Gemini, etc. Si vous changez d’outil ou en utilisez plusieurs, vous conservez agents et compétences.

Limites

• Courbe d’apprentissage : 60+ agents, 260+ compétences, trois modes d’installation, quatre profils, et un lot de variables d’environnement. La première semaine sert surtout à comprendre ce qui est chargé et le rôle de chaque composant.
• Complexité de setup : plugin vs manuel, règles non distribuées via plugin, hooks dupliqués dans d’anciennes versions de Claude Code, flux d’activation MCP, variable de racine de données pour usage multi‑harnais. La doc existe, mais cela reste du travail.
• Maintenance continue : le dépôt évolue régulièrement. Les comptes de catalogues changent et les noms de compétences peuvent évoluer.
• Dépendance à l’écosystème Claude Code : ECC dépend de la spec de plugin, du système de hooks et du support MCP de Claude Code. Quand ces éléments évoluent, ECC doit suivre.
• Sur‑ingénierie pour de nombreux cas : pour beaucoup d’équipes, un CLAUDE.md bien écrit (60‑200 lignes) couvre 80 % d’ECC. Les 20 % restants apportent de la valeur… si vous les utilisez.

Le framework est aujourd’hui la couche de configuration Claude Code la plus complète. Mais « la plus complète » ne signifie pas « nécéssaire pour tous ».

Conclusion

Si vous utilisez Claude Code au quotidien, ECC mérite votre attention. Sinon, le dépôt reste une excellente ressource pour concevoir des workflows d’agents solides en pratique.

Quoi qu’il en soit, ECC illustre clairement l’évolution du développement logiciel vers des pipelines d’agents programmables, loin des sessions de chat ponctuelles. Les frameworks pour bien le faire sont encore jeunes, et ECC est l’une des tentatives les plus complètes à ce jour. Ce ne sera pas la dernière, et c’est tant mieux.

Si vous débutez en IA générative et en codage « agentique », inscrivez‑vous à notre cours Generative AI Concepts. Il vous donnera des fondamentaux solides pour la suite.