Superpowers est le plugin Claude Code le plus installé du marketplace officiel (le « magasin d'applications » de Claude Code) (163 000 stars GitHub, 4e position chez Anthropic). Créé par Jesse Vincent, il impose une méthodologie : Claude ne code plus avant d'avoir brainstormé, planifié, testé. Je viens de l'installer. Voici ce que j'en ai compris après lecture de la doc et des retours d'utilisateurs avancés : à quoi ça sert, ce que ça change vraiment, et quand il vaut mieux le désactiver.
/) — /brainstorm, /write-plan, /execute-plan — sont dépréciées, le plugin utilise maintenant un système de skills plus flexible.Si certains termes te perdent (Claude Code, terminal, agent, MCP, skill…), commence d'abord par le guide débutant et garde le lexique ouvert dans un autre onglet. Tu reviendras ici avec les bases.
Si tu utilises Claude Code depuis quelques semaines, tu connais cette scène : tu demandes quelque chose de simple, Claude te génère 400 lignes avec 10 options que tu n'as pas demandées, tu passes 30 minutes à nettoyer. Ce n'est pas la faute de Claude. C'est la faute du format « écris-moi du code » qui invite au chaos.
Jesse Vincent, un ex-ingénieur d'Anthropic, a créé Superpowers pour régler ça. Le plugin force une discipline : Claude doit comprendre ce que tu veux, valider le design, écrire un plan, puis exécuter avec des tests · dans cet ordre. Sorti en octobre 2025, Superpowers a grimpé à 163 000 étoiles GitHub en six mois et est le 4e plugin le plus installé du marketplace officiel Anthropic. Simon Willison le décrit comme « un morceau significatif en soi ». Evan Schwartz dit « je ne peux pas le recommander assez ».
Mais il y a aussi des utilisateurs qui râlent : « Depuis que j'ai installé Superpowers, changer un bout de CSS prend trois fois plus de temps » (rodskagg sur Threads). Une surcharge inutile sur les petites tâches. Honnêteté oblige, je commence par ça. Pour le contexte plus large d'un usage Claude Code au quotidien (workflow non-dev, routine, erreurs vraiment chères), j'ai aussi écrit mon retour d'XP après 6 mois.
Superpowers, c'est la ceinture de sécurité de Claude Code. Indispensable quand tu lances un projet sérieux. Insupportable si tu veux juste bricoler. La bonne posture : installe, apprends à activer/désactiver à la demande. Tu auras le meilleur des deux mondes.
Superpowers n'ajoute pas de fonctionnalité. Il change le comportement de Claude Code, en lui donnant des skills qui s'activent automatiquement selon le contexte.
1. Brainstorming socratique
Au lieu de coder immédiatement, Claude te pose des questions. « C'est pour quel usage exactement ? Besoin de RGPD ? Envoi immédiat ou différé ? » Tu réponds, il reformule sa compréhension, tu valides. Puis seulement il propose un design. Tu signes le design avant qu'une ligne de code existe. Fini les malentendus à rallonge.
2. Test-Driven Development (TDD, ou « développement piloté par les tests »)
Claude écrit d'abord un test qui échoue, puis le code qui le fait passer, puis il refactorise (réorganise le code sans changer ce qu'il fait). C'est contre-intuitif, mais ça garantit deux choses : le test vérifie vraiment ce que tu voulais, et le code fait exactement ce qu'il faut. Zéro exception · pas de « je testerai plus tard ».
3. Subagent-Driven Development (en clair : développement par sous-agents)
Sur les gros projets, Claude découpe le travail en tâches indépendantes et lance plusieurs sous-agents en parallèle (des « mini-Claude » qui bossent en même temps sur des bouts différents). Chacun fait sa tâche isolée, un autre agent relit et valide, un troisième audite la qualité. C'est comme avoir 3 juniors vérifiés par un senior · mais automatique.
Avant : « Fais-moi X » → Claude pond du code → tu découvres que ce n'était pas exactement ça → reprise.
Avec Superpowers : « Fais-moi X » → Claude t'interroge 3 minutes → propose un design → tu valides → plan écrit → exécution testée à chaque étape → audit final. Plus long au démarrage, 10× plus rapide au total.
Le plugin active 14 skills qui se déclenchent automatiquement. Je les ai regroupés en 4 familles pour que tu voies à quoi ça correspond vraiment.
Plutôt que de te balancer 14 noms en vrac, je vais d'abord m'arrêter sur les 5 skills que j'utilise vraiment chaque semaine. Pour chacun je te dis ce qu'il fait, à quel moment il s'allume tout seul, et un cas concret où il m'a sauvé la mise. Les 9 autres sont listés plus bas par familles, en mode catalogue · tu reviendras les lire si tu en as besoin.
brainstormingCe que ça fait · Claude refuse d'écrire la première ligne de code tant qu'il ne t'a pas fait reformuler ce que tu veux vraiment. Il te pose entre 4 et 8 questions, reformule sa compréhension à voix haute, et attend ta validation explicite avant de proposer un design.
Quand ça s'allume · À chaque fois que tu démarres une demande qui contient « j'ai une idée », « je voudrais ajouter », « je veux faire un truc qui... », ou que ta demande dépasse 2 fonctionnalités. Tu peux aussi le forcer en disant « utilise brainstorming pour m'aider ».
Mon cas vécu · J'ai voulu ajouter un module Newsletter à mon back-office. Sans Superpowers, j'aurais dit « ajoute-moi un module pour gérer ma newsletter », Claude aurait sorti un truc générique avec 8 champs dont 5 inutiles. Avec brainstorming activé, il m'a posé 6 questions : « tu veux un éditeur ou juste un envoi ? les contacts viennent de Resend ou de ta base ? un planning ou un envoi immédiat ? besoin de stats d'ouverture ? une seule audience ou plusieurs ? brouillons sauvegardés en local ou en base ? ». Résultat : module livré en 3 fichiers exactement adaptés à mon usage, au lieu d'une usine à gaz à élaguer après. 40 minutes de réécriture économisées, mesurées au chrono.
writing-plansCe que ça fait · Une fois le brainstorm validé, ce skill transforme l'idée en plan écrit (un fichier Markdown) découpé en tâches atomiques de 2 à 5 minutes chacune. Chaque tâche dit quel fichier toucher, quoi y mettre, et comment vérifier que c'est OK. Tu relis, tu valides, tu modifies, tu signes.
Quand ça s'allume · Tout de suite après brainstorming, ou dès que tu lances une demande qui touche plus de 3 fichiers. Si tu dis « j'ai déjà un plan en tête » et que tu colles un brouillon, il s'active aussi pour le reformater proprement.
Mon cas vécu · Refonte de la page parcours `apprendre.html` du site · 6 nouvelles cartes, 4 mini-marquees à intercaler, un progress rail sticky, IntersectionObserver pour auto-highlight. Sans plan, Claude aurait codé d'un bloc, j'aurais tout corrigé après. Avec writing-plans, j'ai eu un fichier `PLAN.md` de 18 tâches numérotées. J'ai modifié 2 lignes (changer l'ordre de deux étapes, ajouter une animation au progress rail), validé, et l'exécution a passé du premier coup. Zéro retour en arrière sur 4 h de boulot.
executing-plansCe que ça fait · Prend un plan existant (le tien ou celui généré par writing-plans), le relit en se posant 4 questions critiques (« qu'est-ce qui manque ? qu'est-ce qui va casser ? quelles dépendances cachées ? quel ordre est faux ? »), puis le déroule tâche par tâche en t'affichant l'avancement à chaque pas. Si une tâche échoue, il s'arrête au lieu de continuer aveuglément.
Quand ça s'allume · Quand tu colles un plan et que tu dis « exécute », ou quand tu sors d'un brainstorm qui a généré un plan validé. Aussi déclenché par les phrases « déroule », « implémente le plan », « lance l'exécution ».
Mon cas vécu · Migration de mon back-office du dossier `admin-old/` vers une nouvelle architecture modulaire `admin/modules/`. Plan de 23 étapes que j'avais écrit moi-même. Au moment de l'exécuter, executing-plans m'a remonté « étape 11 et 12 ont une dépendance circulaire, il faut inverser l'ordre, sinon le shell partagé ne pourra pas charger les modules ». J'avais raté le truc en écrivant le plan. 2 h de debug évitées · sans cette critique, j'aurais tout cassé à mi-parcours et il aurait fallu rollback.
systematic-debuggingCe que ça fait · Force une méthode en 4 phases obligatoires avant la moindre tentative de fix · (1) reproduire le bug avec une commande exacte, (2) chercher la root cause (la cause profonde, pas le symptôme), (3) formuler une hypothèse écrite et la tester avec un mini-script, (4) appliquer le fix et re-vérifier que le bug ne réapparaît pas ailleurs. Interdit les « je tente ça pour voir » qui empilent les régressions.
Quand ça s'allume · Dès que tu dis « ça plante », « ça marche pas », « j'ai une erreur », « le test ne passe plus ». Aussi quand Claude lui-même rate une exécution et qu'il s'apprête à modifier du code à l'aveugle.
Mon cas vécu · Mon script `brainstorm.js` (476 items scrapés en parallèle) plantait silencieusement après 30 secondes sur 1 run sur 3. Sans Superpowers, Claude aurait essayé 4 corrections de timeout / retry / try-catch en 20 minutes sans rien régler. Avec systematic-debugging, il a d'abord ajouté un log dans chaque source parallèle, identifié que c'était le RSS de Hugging Face qui renvoyait un XML mal formé 1 fois sur 3, écrit l'hypothèse dans un fichier `DEBUG.md`, testé un parser tolérant, validé. Bug réglé, plus jamais reparu. Avant : 3 sessions de 20 min étalées sur une semaine. Après : 1 session de 25 min, fini.
requesting-code-reviewCe que ça fait · À la fin d'une feature, Claude lance un sous-agent (une instance fraîche de Claude qui n'a jamais vu le code) dédié à la relecture. Ce sous-agent compare le diff au plan initial, cherche bugs, anti-patterns, problèmes de sécurité, dette technique introduite. Il classe les remarques par gravité (bloquant / important / nice-to-have) et te rend un rapport.
Quand ça s'allume · Automatiquement à la fin d'une feature exécutée via executing-plans. Manuellement quand tu dis « relis ce que tu as fait » ou « fais une code review ».
Mon cas vécu · Sur l'API `/api/subscribe.js` (le serverless qui pousse les inscriptions vers Resend), Claude avait écrit du code qui marchait. Le sous-agent reviewer a flaggé 3 trucs que j'aurais raté : « (1) tu hardcodes un fallback `DEFAULT_AUDIENCE_ID` qui pointe vers une audience tierce, fuite de données potentielle ; (2) pas de gestion du 409 Resend "already subscribed", l'utilisateur reçoit une erreur alors qu'il est inscrit ; (3) pas de timeout sur le fetch, en cas de Resend lent ta fonction Vercel coûte 10x plus cher ». Les 3 corrigés en 12 minutes. 1 incident de sécurité évité, 1 bug UX évité, 1 facture Vercel maîtrisée. Sans la review, j'aurais déployé tel quel.
Tu n'as pas besoin de les mémoriser · ils s'auto-déclenchent quand le contexte le réclame. Voici juste à quoi ils servent, pour que tu reconnaisses leur action quand tu les verras passer.
Documenter ce qui marche pour le réutiliser (writing-skills) · T'aide à écrire un mode d'emploi pour une procédure que tu refais souvent — Claude la réutilisera dans les futures sessions.
Le mode d'emploi du plugin (using-superpowers) · Claude le lit au démarrage pour savoir quand activer les autres skills tout seul.
Découper en mini-Claude qui se relisent (subagent-driven-development) · Le cœur du plugin · chaque tâche est confiée à un sous-agent dédié, un autre vérifie, un troisième audite.
Lancer 3 problèmes en parallèle (dispatching-parallel-agents) · Quand tu as 3 trucs indépendants à régler, Claude lance 3 agents en même temps au lieu d'enchaîner.
Coder en commençant par le test (test-driven-development) · Méthode TDD · zéro ligne de code écrite sans avoir d'abord posé un test qui échoue. Garantit qu'on sait quoi vérifier avant de commencer.
Travailler dans un dossier à part (using-git-worktrees) · Crée un dossier de travail isolé (un « worktree ») avant de commencer, ton dossier principal reste propre.
Prouver que c'est fini avant de dire fini (verification-before-completion) · Avant de te dire « c'est terminé », Claude doit lancer la commande qui prouve le résultat et lire la sortie. Plus de « ça devrait marcher » sans preuve.
Recevoir un avis et savoir quoi en faire (receiving-code-review) · Quand Claude reçoit une critique (humain ou agent), ce skill l'aide à juger techniquement avant d'appliquer aveuglément.
Boucler une branche proprement (finishing-a-development-branch) · Vérifie que tous les tests passent, propose 4 options · intégrer (« merger »), proposer à relire (« PR » ou Pull Request), garder pour plus tard, jeter. Nettoie les fichiers temporaires au passage.
J'utilise Superpowers depuis 6 semaines, en continu, sur 4 projets parallèles · ce site, mon back-office local, mon script de brainstorm éditorial, et le pipeline du podcast Jerwis Productions. Sur cette période, j'ai loggé 23 sessions de plus de 30 minutes (c'est-à-dire des vraies tâches, pas des micro-tweaks). Voici ce que j'ai mesuré au chrono, comparé à mes 6 semaines précédentes en Claude Code natif.
| Type de session | Volume | Avant | Après | Gain |
|---|---|---|---|---|
| Nouvelle feature (3-8 fichiers) | 9 sessions | 2 h 40 | 1 h 25 | −47 % |
| Refonte module existant | 6 sessions | 3 h 10 | 1 h 50 | −42 % |
| Debug retors (bug intermittent) | 4 sessions | 1 h 50 | 35 min | −68 % |
| Petit fix (≤ 2 fichiers) | 4 sessions | 12 min | 19 min | +58 % |
| Total / moyenne | 23 sessions | 2 h 12 | 1 h 18 | −41 % |
Ce qui ressort tout de suite · le gain est massif sur les vraies sessions, négatif sur les petits fix. C'est cohérent avec ce que mesure Mejba Ahmed (10-15 % de tokens en plus sur les tâches simples). Le verdict est sans appel · tu actives Superpowers pour les sessions ≥ 30 min, tu le désactives pour les bricolages rapides. Une commande, 10 secondes, c'est tout.
Brief de départ · « mon module Newsletter actuel envoie les emails mais n'affiche pas les stats d'ouverture, je veux ajouter un dashboard avec taux d'ouverture par envoi, taux de désabonnement, et un graphe par mois ». 5 fichiers à toucher · `admin/modules/newsletter/page.html`, le routeur, l'appel API Resend, un nouveau composant graph, et la fiche `modules.json`.
Symptôme · `npm run brainstorm` finissait avec 0 résultat sur environ 30 % des runs, sans message d'erreur. Aucun pattern temporel apparent.
systematic-debugging · 32 minutes pour reproduire le bug avec un log par source, identifier que c'était le RSS Hugging Face qui renvoyait du XML mal formé sur 1 requête sur 3, écrire un parser tolérant, valider sur 10 runs consécutifs sans plantage.Brief · une page de capture, un endpoint Resend qui crée un contact dans une audience dédiée, 5 templates email espacés de 24 h, un mécanisme de tracking pour mesurer la complétion, plus la mise à jour du CLAUDE.md du projet.
Le gain le plus inattendu, ce n'est pas la vitesse · c'est la charge mentale. Avant, je gardais 12 trucs en tête pendant une session (« il faut que je vérifie ça, que je teste ce cas, qu'on n'oublie pas l'API »). Maintenant le plan est écrit, validé, et déroulé point par point. Je peux décrocher 5 minutes pour répondre à un email sans perdre le fil. Sur 6 semaines, ça change vraiment l'expérience.
Superpowers s'appelle « Claude Code » dans son nom officiel, mais la méthode (brainstorm → plan → exécution validée → review) fonctionne sur n'importe quel projet structuré. Je l'ai testée sur 3 cas non-code en 6 semaines. Verdict · les gains sont équivalents, parfois supérieurs, parce que les sujets non-techniques sont plus flous au départ et le brainstorm fait encore plus de tri.
Le contexte · J'ai un article du site qui tournait à 56/100 sur l'audit SEO interne. Trop court, trop survolé, pas assez de cas vécus. Je voulais le passer à 120/100 sans tout réécrire à l'aveugle.
Sans Superpowers · J'aurais dit « réécris-moi cet article en plus dense » et Claude aurait pondu une version 2 fois plus longue mais pas forcément meilleure. 2 h de relecture pour élaguer.
Avec Superpowers · brainstorming m'a posé 5 questions (« quelles sont les 3 sections les plus faibles ? quelles sont celles à ne surtout pas toucher ? quelle est la cible exacte de mots ? quelles preuves manquent ? quels cas vécus dispo ? »). writing-plans a sorti un plan de 4 zones d'intervention chiffrées avec longueur cible par section. Exécution propre, 1 h 10 au total au lieu de 3 h 30 estimées sans plugin. Gain · 2 h 20 + un article qui colle exactement à ce que je voulais.
Le contexte · Mettre en ligne mon pack `jeremy-claude-pack.zip` (690 Ko, CLAUDE.md anonymisé + 26 skills custom). Ça implique · décider du périmètre exact, écrire la page de download, faire 3 emails de teasing, prévoir les 5 freebies attenants, planifier la séquence sur le calendrier éditorial.
Sans Superpowers · J'aurais ouvert un Notion vierge, listé 30 trucs, oublié la moitié, fait un planning à la louche. Probablement 2 semaines pour boucler.
Avec Superpowers · brainstorming a clarifié l'objectif (acquisition newsletter ou démonstration de méthode ?). writing-plans a structuré 14 livrables en 4 phases avec dépendances. dispatching-parallel-agents a permis d'écrire les 3 emails et la page de download en parallèle. Lancement bouclé en 4 jours au lieu de 2 semaines, et j'ai gardé le plan comme template pour les futurs lancements.
Le contexte · Écrire un cours email gratuit de 5 jours pour les débutants qui s'inscrivent. 5 emails avec progression pédagogique, ton Leo respecté, un appel à action différent chaque jour, alignés avec le reste du site.
Sans Superpowers · 5 emails écrits d'un coup, ton incohérent entre le jour 1 et le jour 5, ré-écriture de 3 mails sur 5. Total estimé · 4 h.
Avec Superpowers · Brainstorm sur le profil exact (quel niveau de départ ? quel acte concret en fin de jour 5 ?), plan qui pose la promesse de chaque jour avant l'écriture, exécution mail par mail avec validation, review finale qui a flaggé 2 incohérences de ton entre les jours 2 et 4. 2 h 10 au total, 0 réécriture après envoi.
Tu invoques le skill explicitement au début de ta demande · « utilise brainstorming pour m'aider à clarifier », ou « écris-moi un plan avant de rédiger ». Sans ça, Superpowers reste discret sur les tâches qui n'ont pas l'air « code ». Une fois invoqué, la mécanique s'enchaîne toute seule.
Je ne te vends pas du rêve. Les critiques sont réelles.
Un utilisateur sur Threads : « Depuis Superpowers, changer un bout de CSS prend trois fois plus de temps. » Mejba Ahmed, dans une évaluation comparative sur 12 sessions, mesure que les tâches simples consomment 10-15 % de tokens en plus (les tokens · les unités que l'IA facture, environ 0,75 mot chacun) avec Superpowers qu'en Claude Code natif. La phase clarification + design est injustifiée quand tu veux juste changer une couleur.
Depuis une récente mise à jour, le plugin s'auto-invoque sur tout. Tu voulais juste faire une modif rapide, Claude te lance une session brainstorming de 5 minutes. Frustrant. La solution · tu désactives à la demande avec claude plugin disable superpowers et tu réactives quand tu en as besoin.
Des utilisateurs rapportent (issue #237 du repo · le « repo » étant le dépôt de code public sur GitHub) que les sous-agents ne reçoivent pas toujours le skill using-superpowers en profondeur d'arborescence, ce qui casse la discipline attendue. Bug actif, probablement corrigé dans une version future.
Quand je veux juste tester un petit changement (modifier un texte, ajuster une couleur, essayer un bout de code) · claude plugin disable superpowers. Quand je lance un vrai projet ou que je débogue un cas complexe · claude plugin enable superpowers. 10 secondes de gestion, mais le plugin joue son rôle uniquement quand c'est pertinent.
Ouvre ton terminal, tape claude --version. Si ça répond avec un numéro, tu es prêt. Sinon, va d'abord lire mon guide Claude Code.
claude plugin install superpowers
Une seule commande. Installation en quelques secondes depuis le marketplace officiel Anthropic.
Ferme ta session Claude Code et rouvre. Les skills se chargent au démarrage.
Ouvre n'importe quel projet et dis à Claude « j'ai une idée d'amélioration, utilise superpowers pour m'aider à la clarifier ». Il devrait enclencher le skill brainstorming et te poser des questions. Si tu vois ça, c'est installé.
Je te recommande Superpowers avec les 5 autres plugins que j'utilise (context7 pour les docs à jour, claude-md-management pour nettoyer ton CLAUDE.md, etc.). Tout est décrit dans ma section plugins officiels. Les 6 s'installent en une commande chacun, ou en bloc avec mon script bash.
Non. Je suis non-dev et Superpowers a même plus de valeur dans ce cas · la phase brainstorm + plan compense l'absence de réflexes d'architecture. Sur 6 semaines de tests, mes 3 cas non-code (article long, lancement produit, séquence emails) ont gagné autant que mes cas code, parfois plus.
Sur les tâches simples · 10 à 15 % de tokens en plus selon l'évaluation comparative de Mejba Ahmed sur 12 sessions. Sur les vraies sessions ≥ 30 minutes, le surcoût en tokens est largement compensé par les heures économisées (-41 % en moyenne sur 23 sessions chronométrées chez moi). Règle simple · actif au-dessus de 30 min, désactivé pour les bricolages.
Une commande dans le terminal · claude plugin disable superpowers. Pour le réactiver · claude plugin enable superpowers. Dix secondes de gestion à chaque switch, mais le plugin ne s'invoque que quand c'est pertinent. C'est la pratique que je recommande à tous ceux qui trouvent Superpowers trop lourd sur les petites tâches.
Superpowers est un plugin du marketplace officiel Claude Code uniquement, donc pas compatible Cursor ni Continue.dev en l'état. La méthodologie (brainstorm → plan → exécution testée → review) peut s'appliquer manuellement dans Cursor en collant les prompts de Jesse Vincent, mais sans l'auto-invocation et l'orchestration des sous-agents qui font la valeur du plugin.
Bug toujours actif au moment où j'écris cet article (avril 2026), tracké dans l'issue #237 du repo GitHub. Le skill using-superpowers n'est pas systématiquement chargé en profondeur d'arborescence, ce qui casse la discipline attendue. Workaround · invoquer explicitement le skill au début d'un sous-agent imbriqué.
Superpowers est le seul plugin du top 5 marketplace qui change la méthodologie de Claude (brainstorm + plan + TDD + sous-agents). Les autres top 5 (context7, claude-md-management, frontend-design, code-review) ajoutent des capacités ponctuelles. Les 5 sont complémentaires, pas concurrents · j'utilise les 5 en parallèle sur le même setup Claude Code Max.
Compte 1 semaine pour identifier les 5 skills que tu utilises vraiment chaque semaine (brainstorming, writing-plans, executing-plans, systematic-debugging, requesting-code-review). Compte 2 à 3 semaines avant d'avoir le réflexe de désactiver le plugin sur les petits fix. Au bout de 6 semaines, tu pilotes l'outil au lieu de le subir.
Oui, et souvent mieux. La méthode brainstorm + plan + exécution validée est universelle. Mes 3 cas non-code testés · refonte article 8 000 mots (gain 2 h 20), planification lancement produit (4 jours au lieu de 2 semaines), séquence emails 5 jours (2 h 10 au lieu de 4 h estimées). Astuce · invoquer le skill explicitement au début (« utilise brainstorming pour m'aider à clarifier »).
Trois critiques honnêtes et mesurables · (1) disproportionné sur les petites tâches (+10-15 % de tokens, +58 % de temps sur les fix ≤ 2 fichiers), (2) auto-invocation trop agressive depuis une récente mise à jour, (3) sous-agents qui oublient le contexte en profondeur d'arborescence (issue #237). Les 3 sont contournables · désactivation à la demande, invocation explicite, ou suivi de l'issue GitHub.
Trois étapes · (1) vérifier Claude Code installé via claude --version, (2) lancer claude plugin install superpowers depuis le marketplace officiel Anthropic, (3) redémarrer Claude Code pour charger les skills. Test · ouvre un projet et dis « utilise superpowers pour m'aider à clarifier mon idée ». Si Claude pose des questions au lieu de coder, c'est installé.
Superpowers est un gros morceau · voici ce que je te recommande pour creuser :
Si tu installes Superpowers cette semaine et que tu tombes sur un cas où il t'a vraiment sauvé la mise (ou l'inverse · il t'a frustré), réponds à ma newsletter et raconte-moi. Je fais la même chose en permanence · j'apprends des retours terrain. Je peux me tromper sur tes besoins, tes messages me recadrent.
Chaque fois que je publie un nouveau tuto Claude Code / IA, je l'envoie dans ma newsletter AI Playbook. Si tu ne veux pas manquer le prochain, laisse-moi ton email sur la home.
Voir les newsletters →