Claude Code : l’IA qui code, débugue et livre depuis votre terminal

Demandez à Claude Code de refactorer un module JavaScript en TypeScript, d’écrire les tests unitaires, de les exécuter et de corriger les échecs — dans une seule instruction. Il le fait. Il navigue dans votre arborescence de fichiers, lit le code existant pour comprendre les conventions, produit des modifications cohérentes avec le style du projet, et vérifie son propre travail. Ce n’est pas un gadget de démonstration : des équipes de développement l’utilisent huit heures par jour comme collaborateur de production.

Cet article est le septième de la série « De zéro à machine de guerre avec Claude ». Après les fichiers bureautiques (article 6), on passe au terrain où Claude domine le marché en avril 2026 : le code. Et si vous n’êtes pas développeur, restez : la section sur le « vibe coding » vous concerne directement.

Trois interfaces, un même moteur

Claude Code existe sous trois formes. Le CLI (Command Line Interface) : vous tapez claude dans votre terminal, et vous interagissez avec l’agent directement en ligne de commande. C’est la forme originale, lancée en février 2025, la plus puissante et la plus flexible. L’application desktop, entièrement repensée le 14 avril 2026 pour piloter plusieurs Claude en parallèle. Et l’extension IDE (VS Code, Cursor, Windsurf, JetBrains) qui affiche les diffs en temps réel dans votre éditeur.

Les trois partagent le même moteur, la même authentification, et le même historique de conversation. Vous pouvez démarrer une session dans le CLI et la reprendre dans le desktop avec claude --resume. L’extension VS Code inclut le CLI — pas besoin d’installer les deux séparément.

Installation en 5 minutes

Le desktop redesign du 14 avril 2026

Ce n’est plus une fenêtre de chat avec un terminal en arrière-plan : c’est un vrai dashboard d’agents. Le changement central est la barre latérale multi-sessions. Vous lancez un refactoring sur un dépôt, un fix de bug sur un autre, une passe de tests sur un troisième — et vous passez de l’un à l’autre comme des onglets de navigateur. Chaque session tourne dans son propre Git worktree isolé : les modifications d’une session n’affectent pas les autres tant qu’elles ne sont pas committées.

Anthropic a intégré les outils qu’on allait chercher ailleurs : un terminal intégré (lancez npm test sans quitter l’app), un éditeur de fichier in-app pour les retouches rapides, un diff viewer reconstruit pour les gros changesets, et un panneau de preview qui affiche les fichiers HTML, PDF et les serveurs d’app locaux. Tous les panneaux sont repositionnables par glisser-déposer.

Le raccourci qui change tout : Cmd+; (ou Ctrl+;) ouvre un side chat qui branche une question hors du thread principal, sans polluer le contexte de la session en cours. Vous pouvez poser une question latérale à Claude sans casser son raisonnement sur la tâche principale.

Le redesign est disponible pour tous les plans payants (Pro, Max, Team, Enterprise). Le CLI reste intact et continue de fonctionner — beaucoup de développeurs utilisent les deux : CLI pour les tâches rapides, desktop pour les sessions longues ou multi-projets.

CLAUDE.md : la fondation de tout le reste

Le fichier CLAUDE.md est l’équivalent des instructions de Project pour Claude Code. Il est lu au début de chaque session et donne à Claude le contexte permanent du projet. La différence avec les Projects de claude.ai : CLAUDE.md vit dans votre repository Git, versionné avec votre code. Quand vous changez de branche, les instructions changent avec.

Un bon CLAUDE.md contient les règles qui s’appliquent à chaque tâche — pas les workflows ponctuels (ceux-là iront dans les skills, on y revient). Voici la structure qui marche en pratique :

# CLAUDE.md — structure efficace
# Projet : Dashboard Analytics

## Stack et versions
- Backend : FastAPI 0.115 + Python 3.12
- Frontend : React 18 + TypeScript strict (noImplicitAny)
- Base de données : PostgreSQL 16
- Gestionnaire : pnpm (PAS npm, PAS yarn)

## Règles non-négociables
- Type hints obligatoires sur toutes les fonctions Python
- Composants React fonctionnels uniquement, pas de classes
- Imports absolus, jamais de ../../..
- Commits : feat:, fix:, chore:, docs: en préfixe
- Ne JAMAIS modifier les fichiers dans src/legacy/
- Ne JAMAIS commit sans avoir lancé `pnpm test`

## Commandes du projet
- Dev : `pnpm dev`
- Tests : `pnpm test` (backend) et `pnpm test:ui` (frontend)
- Build : `pnpm build`
- Lint : `pnpm lint --fix`

## Pièges connus
- La table `users` a une colonne `status` qui accepte
  null — toujours filtrer `WHERE status IS NOT NULL`
- Les tests d'intégration nécessitent Redis local port 6379
- L'API auth renvoie 401 au lieu de 403 sur les permissions
  manquantes (legacy, à ne pas corriger)

## Architecture en bref
- `/src/api` : endpoints FastAPI (1 fichier par resource)
- `/src/core` : logique métier pure, pas de dépendances web
- `/src/db` : modèles SQLAlchemy et migrations Alembic
- `/web` : frontend React (Vite + Tailwind)

Trois règles pour garder un CLAUDE.md efficace. Court et lisible : 50-100 lignes maximum. Tout ce qui est long et spécifique à une tâche devient un skill, pas une règle globale. Actionnable : chaque ligne doit permettre à Claude de prendre une décision. « Notre code est propre » n’est pas actionnable. « Pas de fonctions de plus de 40 lignes » l’est. Maintenu : quand Claude se trompe systématiquement sur un point, ajoutez la règle. Quand une règle n’est plus vraie, retirez-la.

Règles modulaires pour les gros projets

Pour les monorepos, Claude Code propose le dossier .claude/rules/. Au lieu de tout empiler dans un seul CLAUDE.md, vous créez des fichiers séparés par domaine :

# Arborescence pour monorepo
.claude/
├── rules/
│   ├── python-backend.md       (règles backend)
│   ├── react-frontend.md       (règles frontend)
│   ├── sql-migrations.md       (règles DB)
│   └── security.md             (règles sécurité transverses)
CLAUDE.md                       (vision générale + pointeurs)

Cette granularité évite les conflits de merge sur le CLAUDE.md principal et permet à chaque équipe de maintenir ses propres règles sans toucher à celles des autres.

Prompter Claude Code : ce qui marche vraiment

Le plus gros levier de performance avec Claude Code, ce n’est pas la puissance du modèle — c’est votre façon de lui parler. Un prompt bâclé donne un résultat bâclé, même sur Opus 4.6. Voici les cinq réflexes qui transforment les résultats.

1. Commencer par un plan, pas par du code

Pour toute tâche non-triviale, demandez d’abord un plan. Pas une exécution. « Avant d’écrire quoi que ce soit, lis les fichiers concernés et fais-moi un plan de ce que tu vas modifier. Je valide avant que tu touches au code. » Claude produit un plan, vous le corrigez ou validez, puis il exécute. Cette étape prend deux minutes et évite trente minutes de rollback sur une mauvaise direction.

Le mode plan est intégré : Shift+Tab dans le CLI ou le bouton Plan dans le desktop. Dans ce mode, Claude ne modifie rien — il lit, réfléchit, et propose. Vous passez en mode exécution quand le plan est bon.

2. Donner le scope et les contraintes explicites

Claude Code prend les instructions au premier degré. Si vous dites « ajoute un endpoint », il peut en profiter pour refactorer trois autres fichiers qu’il juge sales. Soyez explicite sur ce qu’il ne doit pas toucher.

# Prompt bâclé (résultat imprévisible)
Ajoute un endpoint pour récupérer les utilisateurs.

# Prompt efficace (résultat contrôlé)
Ajoute un endpoint GET /api/users qui retourne la liste
des utilisateurs actifs (status='active').

Contraintes :
- Ne modifie QUE src/api/users.py
- Suis le pattern des endpoints existants dans ce fichier
- Ajoute les tests correspondants dans tests/api/test_users.py
- Ne touche pas aux autres endpoints ni aux modèles
- Lance `pnpm test tests/api/test_users.py` pour valider

3. Demander des critères d’acceptation

À la place de « corrige ce bug », formulez « corrige ce bug. Le test qui doit passer : quand un utilisateur sans email se connecte, l’app affiche la page de saisie d’email au lieu de crasher. Écris ce test d’abord, puis corrige. » Vous transformez une instruction floue en spécification vérifiable. Claude écrit le test, le voit échouer, corrige, le voit passer — et vous avez un test de régression en prime.

4. Laisser Claude poser des questions

Pour une tâche ambiguë, ajoutez : « Avant de commencer, pose-moi les questions dont tu as besoin pour éviter les hypothèses. » Claude utilise l’outil AskUserQuestion et vous lance 3-5 questions précises. Vous répondez, il démarre avec une base solide. Deux minutes de questions valent mieux qu’une heure de réimplémentation.

5. Challenger le résultat

Après une modification non-triviale : « Prouve-moi que ça marche. Montre-moi le diff entre main et ta branche, lance les tests, et explique pourquoi tu es confiant que rien n’est cassé. » Ou encore : « Grille-moi sur ces changements comme si tu étais un staff engineer en code review. Ne merge pas tant que tu n’as pas trouvé au moins trois faiblesses. » Claude est capable d’auto-critique sévère si on le lui demande.

Cinq workflows concrets, étape par étape

Workflow 1 : débugger un crash en production

Vous avez un stack trace. Vous ne savez pas d’où ça vient. Prompt à coller dans Claude Code :

# Prompt debug
J'ai ce crash en prod. Avant de corriger :

1. Lis le stack trace ci-dessous et identifie le fichier
   et la ligne où ça casse
2. Lis ce fichier pour comprendre la fonction concernée
3. Cherche dans le code où cette fonction est appelée
4. Formule 3 hypothèses sur la cause racine
5. Pour chaque hypothèse, dis-moi comment la vérifier
6. ATTENDS ma validation avant de modifier quoi que ce soit

Stack trace :
[coller ici]

Claude lit, analyse, vous propose 3 pistes. Vous choisissez la plus plausible, il vérifie sur le code, confirme, et propose le fix. Cette structure évite le « je corrige au petit bonheur » qui masque le vrai bug et en crée d’autres.

Workflow 2 : migrer un module JavaScript vers TypeScript

Pour une migration, la clé est de procéder par vagues et de garder les tests verts à chaque étape.

# Prompt migration JS -> TS
On migre src/utils/ de JavaScript vers TypeScript.

Procède par vagues d'UN fichier à la fois :
1. Convertis le fichier .js en .ts avec types stricts
2. Remplace les `any` par les vrais types dès que possible
3. Mets à jour les imports dans les fichiers qui l'utilisent
4. Lance `pnpm test` et `pnpm tsc --noEmit`
5. Si tout est vert, commit avec message `chore: migrate
    to TypeScript`
6. Passe au fichier suivant

Commence par les fichiers sans dépendances internes.
Arrête-toi si un test casse et demande-moi quoi faire.

Claude ordonne les fichiers par dépendances, traite le premier, teste, commit, passe au suivant. Vous obtenez une série de commits atomiques et réversibles, pas une grosse PR monolithique.

Workflow 3 : refactorer un gros module

Pour un refactoring de 500+ lignes, la tentation est de tout réécrire d’un coup. Mauvaise idée. Le bon pattern : caractériser avant de toucher.

# Prompt refactoring sûr
On va refactorer src/core/billing.py.

Phase 1 — Caractérisation (PAS de modif) :
- Lis le fichier entier
- Identifie les fonctions publiques et leurs signatures
- Pour chaque fonction publique, écris un test qui
  capture son comportement actuel dans tests/core/
  test_billing_characterization.py
- Lance les tests, tous doivent passer sur le code actuel

ATTENDS ma validation avant la phase 2.

Phase 2 — Refactoring :
- Propose un plan avant de toucher au code
- Applique le plan fonction par fonction
- Les tests de caractérisation DOIVENT rester verts
  à chaque étape

Les tests de caractérisation sont votre filet. Si Claude casse un comportement pendant le refactoring, le test vire au rouge et vous l’arrêtez.

Workflow 4 : ajouter une feature de A à Z

Une vraie feature implique modèles, API, frontend, tests. Le prompt qui marche découpe en phases avec validation entre chaque :

# Prompt feature complète
Feature : export CSV de la liste des commandes.

Plan d'exécution en 4 phases, validation à chaque étape :

Phase 1 — Modèle + endpoint backend
- Fonction `export_orders_csv(filters)` dans core/orders.py
- Endpoint GET /api/orders/export dans api/orders.py
- Tests unitaires du core, tests d'intégration de l'API
- STOP, je valide

Phase 2 — Frontend
- Bouton "Exporter CSV" dans la page OrdersList
- Appel API, gestion loading + erreur
- Téléchargement du fichier côté navigateur
- STOP, je valide

Phase 3 — Tests end-to-end
- Scénario Playwright : clic bouton -> fichier téléchargé
- STOP, je valide

Phase 4 — Doc
- Ajoute la feature dans docs/features.md
- Message de commit propre par phase

Commence par la phase 1.

Workflow 5 : onboarding sur un codebase inconnu

Nouveau poste, nouveau projet, 50 000 lignes de code que vous ne connaissez pas. Claude Code est imbattable sur ce cas d’usage.

# Prompt onboarding
Je suis nouveau sur ce codebase. Fais-moi :

1. Un diagramme d'architecture en ASCII ou mermaid,
   niveau "macro" (3-5 blocs principaux et leurs relations)
2. La liste des 10 fichiers les plus critiques à comprendre
   en premier, avec 2 lignes d'explication chacun
3. Les patterns récurrents du projet (naming, organisation,
   conventions implicites qui ne sont pas dans le README)
4. Les 5 "zones suspectes" que tu sens fragiles, datées,
   ou qui mériteraient un refactoring
5. Un quiz de 10 questions que je devrais savoir répondre
   après avoir bien assimilé le projet

Ne modifie rien. Produis le tout dans un fichier
docs/ONBOARDING.md.

Vous passez d’une journée perdue à lire du code sans fil directeur à une carte utilisable en vingt minutes.

Skills, hooks, plugins : la couche automation

Une fois les bases acquises, vous allez vous rendre compte que vous tapez les mêmes instructions en boucle. C’est le signal : il est temps de passer aux skills.

Les skills : vos workflows réutilisables

Un skill est un fichier markdown (SKILL.md) qui encode un workflow. Vous le stockez dans ~/.claude/skills/<nom>/SKILL.md (usage personnel) ou .claude/skills/<nom>/SKILL.md (partagé avec l’équipe via le repo). Claude le charge automatiquement quand une requête utilisateur matche la description du skill.

# Exemple : .claude/skills/pr-review/SKILL.md
---
name: pr-review
description: >
  Lance une revue de PR complète : lit le diff,
  vérifie les conventions du projet, cherche les
  bugs potentiels et les régressions, produit un
  commentaire structuré. Utilise quand l'utilisateur
  demande "review cette PR" ou fournit un numéro de PR.
---

# Revue de PR

Pour chaque PR à reviewer :

1. Lis le diff complet avec `gh pr diff `
2. Vérifie les points suivants dans l'ordre :
   - Conventions de code (cf CLAUDE.md)
   - Tests ajoutés pour les nouveaux comportements
   - Pas de régression potentielle sur les zones touchées
   - Pas de secret hardcodé (cherche 'key', 'token', 'password')
   - Messages de commit conformes (feat:/fix:/chore:)

3. Produis un commentaire structuré :
   ## Ce qui est bien
   ## À corriger avant merge
   ## Suggestions (non bloquantes)

4. Poste via `gh pr review  --comment -F -`

À l’usage, vous tapez « review la PR #142 », Claude active le skill pr-review, et déroule le workflow. Chaque équipe construit sa propre bibliothèque : release notes, scaffolding de tests, post-mortem, génération de migrations SQL. Les skills sont versionnés avec le code, partagés via le repo, améliorés au fil du temps.

La règle : écrivez trois skills avant de toucher aux plugins. Pickez trois workflows que votre équipe répète chaque semaine, capturez-les en markdown. Vous apprendrez plus sur Claude Code en faisant ça qu’en lisant toute la documentation.

Les hooks : l’automation déterministe

Les hooks sont des commandes shell qui se déclenchent à des moments précis du cycle de vie de Claude : avant un outil (PreToolUse), après (PostToolUse), au démarrage d’une session (SessionStart), quand Claude s’arrête (Stop), quand vous postez un message (UserPromptSubmit).

Cas d’usage concrets : formater automatiquement les fichiers après édition (Prettier, Black), bloquer l’écriture de fichiers sensibles (.env, *.pem), envoyer une notification desktop quand Claude a besoin de votre validation, logger chaque changement pour audit. Exemple d’un hook qui formate le code Python après chaque édition :

# ~/.claude/settings.json
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [{
          "type": "command",
          "command": "jq -r '.tool_input.file_path' | grep '\\.py$' | xargs -r black"
        }]
      }
    ]
  }
}

Les hooks sont déterministes : ils tournent systématiquement, pas « si Claude y pense ». Quand une règle doit absolument être appliquée (linting, checks de sécurité, audit), c’est un hook qu’il faut, pas une instruction dans CLAUDE.md.

Les plugins : packager et distribuer

Un plugin est un bundle qui contient des skills, des hooks, des subagents, des slash commands, et éventuellement des serveurs MCP. Vous l’installez via un marketplace (/plugin install <name>). C’est la façon de distribuer des capacités complètes à votre équipe ou à la communauté.

Conseil de sagesse : installez le moins de plugins possible. Chaque plugin ajoute à votre contexte de base, et la limite Claude Code (environ 2 % de la fenêtre pour les descriptions de skills) est vite atteinte. Les meilleurs utilisateurs de Claude Code tournent avec 2-3 plugins max, voire zéro, en s’appuyant sur un CLAUDE.md précis et des skills locaux.

Auto Memory et checkpoints : coder sans perdre le fil

En plus du CLAUDE.md que vous écrivez, Claude Code maintient sa propre mémoire automatique. Pendant qu’il travaille, il note ce qu’il apprend : commandes de build qui ont marché, patterns de debug découverts, décisions d’architecture. Ces notes sont stockées dans ~/.claude/projects/<projet>/memory/ et relues au début de chaque session.

Vous pouvez aussi dicter explicitement : « Retiens qu’on utilise pnpm, pas npm ». Tapez /memory en session pour voir et modifier tout ce que Claude a retenu. Depuis mars 2026, Auto Dream consolide automatiquement cette mémoire : fusion des doublons, nettoyage des notes obsolètes, conversion des dates relatives en absolues.

Les checkpoints sont l’autre filet de sécurité. Quand Claude Code modifie votre code, il crée automatiquement un instantané de l’état précédent. Double Esc dans le CLI, ou bouton de rewind dans le desktop : vous revenez en arrière instantanément. Trois options : revenir au code uniquement (en gardant la conversation), à la conversation uniquement (en gardant le code), ou aux deux. C’est l’équivalent d’un Ctrl+Z illimité au niveau du projet entier — et c’est ce qui permet de lancer Claude sur des tâches ambitieuses sans peur.

Les routines : Claude Code qui tourne pendant que vous dormez

Depuis le 14 avril 2026, Claude Code peut exécuter des tâches de façon autonome sur l’infrastructure cloud d’Anthropic, même quand votre machine est éteinte. C’est le concept des routines : une configuration sauvegardée (prompt, dépôt GitHub, connecteurs MCP) qui s’exécute automatiquement selon un déclencheur.

Trois types de déclencheurs

• Planification — la routine s’exécute selon un calendrier récurrent. Toutes les heures, chaque nuit, chaque semaine. L’intervalle minimum est d’une heure.
• API — chaque routine reçoit son propre endpoint HTTP et un token d’authentification. Un appel POST depuis n’importe quel outil (CI/CD, monitoring, cron externe) suffit à déclencher une session.
• Webhook GitHub — la routine réagit à des événements sur un dépôt connecté : ouverture de PR, push, création d’issue, déclenchement de workflow.

Une même routine peut combiner plusieurs déclencheurs. Elle tourne en autonomie complète — pas de mode permission, pas d’approbation pendant l’exécution. Le prompt que vous rédigez doit donc être autonome et explicite sur ce que Claude doit accomplir et ce à quoi ressemble le succès.

Six cas d’usage qui font gagner des heures

• Gestion du backlog — chaque soir, identifier les nouveaux tickets, attribuer un responsable et poster un résumé dans Slack.
• Mise à jour de documentation — chaque semaine, repérer les pages qui référencent des API modifiées et ouvrir des PR de correction.
• Vérification post-déploiement — le pipeline CI appelle l’endpoint, Claude teste le build et poste un go/no-go dans le canal de release.
• Triage des alertes — l’outil de monitoring appelle l’endpoint, Claude corrèle la stack trace avec les commits récents et propose un correctif.
• Portage de librairie — chaque PR fusionnée sur un SDK Python déclenche le portage vers le SDK Go et ouvre la PR correspondante.
• Code review sur mesure — à l’ouverture d’une PR, Claude applique la checklist interne et laisse des commentaires avant la relecture humaine.

La création se fait depuis l’interface web (claude.ai/code/routines), depuis le CLI avec /schedule, ou depuis le desktop via Schedule > New task > New remote task. Vous configurez le prompt, les dépôts GitHub à cloner, l’environnement cloud (accès réseau, variables d’environnement), les déclencheurs, et les connecteurs MCP (Slack, Linear, Google Drive). Les routines sont en research preview et disponibles sur les plans Pro, Max, Team et Enterprise, avec des plafonds journaliers (5 exécutions par jour en Pro, 15 en Max, 25 en Team/Enterprise).

Le mode Auto pour les sessions longues

Le mode Auto, lancé en mars 2026, permet à Claude Code de travailler sans approbation manuelle à chaque étape. En mode par défaut, vous validez chaque action sensible. En mode Auto, Claude prend les décisions de permission avec des garde-fous intégrés — moins d’interruptions que le mode par défaut, moins de risque que le flag --dangerously-skip-permissions qu’il remplace.

Il est particulièrement utile pour les sessions longues où l’approbation répétée casse le rythme : un refactoring de 200 fichiers, une migration de framework, une passe de tests exhaustive. Activation : touche Shift+Tab pour basculer entre les modes dans le CLI, ou menu Permissions dans le desktop.

Le vibe coding : Claude Code pour les non-développeurs

Pendant les fêtes 2025-2026, Claude Code est devenu viral auprès d’un public inattendu : des non-programmeurs qui l’utilisaient pour construire des applications, des sites web, des outils internes — simplement en décrivant ce qu’ils voulaient en langage naturel. Le phénomène a été baptisé « vibe coding ».

Le principe : vous décrivez le résultat souhaité en français, Claude Code écrit le code, l’exécute, corrige les erreurs, et vous livre un résultat fonctionnel. « Crée-moi une app web avec un formulaire de contact, une page d’accueil et un blog, design moderne. » Claude choisit la stack, génère les fichiers, lance le serveur de dev, et vous montre le résultat.

Les limites sont réelles : sans connaissances techniques, vous ne pouvez pas évaluer la qualité du code produit, ni le maintenir facilement. Mais pour des prototypes, des outils internes, ou des projets personnels, le vibe coding rend la programmation accessible à quiconque sait décrire clairement ce qu’il veut — et c’est exactement la compétence de prompting que vous avez développée dans les articles précédents de cette série.

Ce que cela change pour vous

Le vrai basculement avec Claude Code n’est pas technique, il est mental. Vous arrêtez de penser « je code avec un assistant » et vous commencez à penser « je dirige un collaborateur ». Le plus gros progrès vient quand vous passez trois heures à écrire un CLAUDE.md précis et trois skills adaptés à votre projet — pas quand vous installez un nouveau modèle.

Les développeurs qui tirent le maximum de Claude Code en 2026 ne sont pas ceux qui ont les meilleurs prompts ponctuels. Ce sont ceux qui ont systématiquement encodé leur expertise en règles, skills et routines réutilisables. Chaque heure investie dans la configuration se rembourse en semaines d’exécution.

Si vous êtes développeur, l’ordre d’attaque est simple. Semaine 1 : installez, créez un CLAUDE.md de 50 lignes pour votre projet principal, faites-vous la main sur les cinq workflows de cet article. Semaine 2 : identifiez vos trois tâches les plus répétitives et écrivez-les en skills. Semaine 3 : mettez en place une routine sur le cas d’usage le plus évident (triage de backlog, review auto, docs drift). À la fin du mois, vous ne reviendrez pas en arrière.

Si vous n’êtes pas développeur mais que vous avez un projet en tête — un outil interne, un site, un prototype — lancez-vous en vibe coding. Le pire qui puisse arriver, c’est que ça ne marche pas du premier coup. Le meilleur : vous avez un produit fonctionnel en quelques heures.

Dans le prochain article, on connecte Claude à vos outils du quotidien : Google Drive, Gmail, Slack, Canva, et tous les connecteurs MCP qui transforment Claude d’un assistant isolé en un hub de productivité branché sur votre écosystème.