Brancher ses outils à l’IA avec les MCP, sans tout automatiser

Pendant longtemps, mon assistant IA vivait dans un onglet à part. Je copiais un ticket, je collais une capture, je recopiais une couleur depuis la maquette, puis je refaisais le chemin inverse pour reporter la réponse ailleurs. L’IA allait vite, moi je faisais le facteur.

Les MCP ont changé ça. Pas de façon spectaculaire : ils ont surtout supprimé les allers-retours.

Un MCP, concrètement

MCP veut dire Model Context Protocol. C’est un format commun qui permet à un assistant (Claude (nouvel onglet), Cursor (nouvel onglet)…) de lire et d’agir dans un autre outil : ouvrir un fichier Figma (nouvel onglet), lister des tickets, publier un élément du CMS Webflow (nouvel onglet).

Chaque outil expose un « serveur » MCP avec une liste d’actions. On le branche une fois, on donne les autorisations, et l’assistant peut ensuite s’en servir quand la tâche le demande. Au lieu de lui décrire mon projet, je le laisse aller voir.

Ce que j’ai branché

Je n’ai pas tout connecté. Seulement les outils où je passais mon temps à recopier des informations.

Outil	Ce que je lui demande
Figma (nouvel onglet)	Lire une frame, ses variables et ses espacements avant d’écrire le composant
Linear (nouvel onglet)	Retrouver le ticket, le mettre à jour quand le correctif est en ligne
Feedbucket (nouvel onglet)	Lire les retours clients avec leur capture, leur page et leur navigateur
Webflow (nouvel onglet)	Vérifier ou préparer des contenus du CMS sans cliquer dans l’éditeur
Vercel (nouvel onglet)	Lire les logs d’un déploiement qui a échoué
GitHub (nouvel onglet)	Relire une pull request avec le contexte du ticket

Le brancher dans Claude

J’utilise Claude (nouvel onglet) à deux endroits : l’application pour réfléchir, rédiger et trier, et Claude Code dans le terminal pour tout ce qui touche au code. Les deux se branchent différemment.

Dans l’application

Dans les paramètres, la rubrique Connecteurs liste les outils déjà prêts à l’emploi. On en choisit un, on se connecte avec son compte de l’outil, et on accepte les autorisations demandées. Pour un outil qui n’est pas dans la liste, on peut ajouter un connecteur personnalisé à partir de l’adresse de son serveur MCP, donnée dans sa documentation.

Ensuite, je n’active pas tout dans chaque conversation. Le menu des outils, sous la zone de saisie, permet d’allumer seulement les connecteurs utiles à la tâche : Figma et Linear pour un composant, Feedbucket et Linear pour une série de retours.

Dans Claude Code

Dans le terminal, un serveur s’ajoute en une ligne, au niveau du projet :

# Serveur distant : Linear
claude mcp add --transport http linear https://mcp.linear.app/mcp

# Serveur local : Figma, servi par l’application desktop (Dev Mode)
claude mcp add --transport http figma http://127.0.0.1:3845/mcp

La commande /mcp, dans une session, affiche les serveurs branchés, leur état, et lance la connexion quand un serveur demande un compte. C’est aussi là que je vérifie qu’un serveur répond avant de lui confier une tâche.

Savoir ce que chaque MCP sait faire

Un serveur MCP, c’est une liste d’outils, au sens technique : des actions précises, avec un nom et une description. Avant de m’en servir, je lis cette liste. Ça prend cinq minutes et ça évite les mauvaises surprises.

Le plus simple, c’est de demander : « Liste les outils du serveur Figma, et dis-moi lesquels lisent et lesquels modifient. » Dans Claude Code, /mcp montre aussi le détail de chaque serveur.

Ce que je regarde :

• Lecture ou écriture. Lire une frame ou un ticket ne casse rien. Créer, modifier, publier ou supprimer, si. Je repère ces outils-là en premier.
• Ce que l’outil renvoie. Le serveur Figma, par exemple, sait renvoyer le contexte d’une sélection (structure et styles), ses variables, ou une capture de la frame. Selon la tâche, je ne demande pas la même chose.
• Le périmètre. Un outil qui lit « tous les projets » ou « toutes les collections » mérite une consigne claire : je précise toujours le fichier, l’équipe ou la collection.
• Ce qui manque. Si l’action dont j’ai besoin n’existe pas, je le sais avant de lancer la tâche, pas au milieu.

Quand un outil d’écriture ne me sert à rien, je le désactive. Moins il y a d’actions possibles, moins l’assistant en choisit une mauvaise.

Trois enchaînements que j’utilise vraiment

Du retour client au correctif

Un client laisse un retour sur la préproduction : « le bouton passe sous le menu sur mon téléphone ». Avant, je lisais le retour, j’ouvrais la capture, je cherchais la page, je devinais le navigateur.

Maintenant, je demande à l’assistant de lire le retour. Il récupère la capture, l’URL, la taille d’écran et le navigateur, retrouve le composant dans le code et me propose une correction. Je relis, je teste sur un vrai téléphone, je valide. Il répond ensuite sur le retour et passe le ticket en « fait ».

Le diagnostic reste à moi. Ce qui a disparu, c’est la demi-heure de collecte.

De la maquette au composant

Sur un composant, je pointe la frame Figma (nouvel onglet) plutôt que de la décrire. L’assistant lit les vraies valeurs : les variables de couleur, les rayons, les espacements de l’auto layout. Il ne devine plus un 16px là où la maquette disait --space-4.

J’en ai parlé dans Du Figma au composant : ce qui se perd entre la maquette et le code, ce sont les intentions. Le MCP ne les invente pas, mais il arrête au moins de perdre les chiffres.

Le CMS sans l’éditeur

Sur un site Webflow (nouvel onglet), il y a toujours une série de petites tâches pénibles : remplir les textes alternatifs de quarante images, vérifier que chaque article a une description, harmoniser des slugs. Je les fais faire par l’assistant, en brouillon, puis je relis avant de publier.

Garder la main pendant que ça tourne

Le risque, avec un assistant branché partout, c’est de le laisser filer et de découvrir le résultat à la fin. Je fais l’inverse : je découpe, et je regarde à chaque étape.

D’abord le plan, ensuite les actions

Je commence par demander ce qu’il compte faire, sans rien toucher : quels retours il va lire, quels fichiers il va modifier, dans quel ordre. Dans Claude Code, le mode plan (Maj + Tab) sert exactement à ça : l’assistant explore et propose, mais ne modifie rien tant que je n’ai pas validé.

C’est souvent à ce moment que je corrige le tir : « non, pas ce composant-là », « laisse les retours déjà traités ». Corriger un plan coûte une phrase. Corriger dix fichiers coûte une heure.

Valider chaque action sensible

Par défaut, Claude demande l’autorisation avant d’utiliser un outil MCP. Je réponds « une fois » pour tout ce qui écrit, et je ne passe en « toujours autoriser » que pour les lectures que j’ai déjà vues tourner. Dans Claude Code, chaque outil a un nom du type mcp__figma__…, ce qui permet d’autoriser une lecture précise sans ouvrir tout le serveur.

Cette petite friction est voulue. Chaque demande d’autorisation est un moment où je vois ce qui se passe, au lieu de le découvrir après.

Avancer par petites étapes

Je ne lance pas « traite tous les retours de la semaine ». Je lance « traite le premier retour, montre-moi le correctif, attends ». Une fois le premier validé, je peux enchaîner plus vite sur les suivants, parce que je sais comment il s’y prend.

Si quelque chose part de travers, j’arrête tout de suite (Échap dans Claude Code) et je reprends avec une consigne plus précise. Arrêter tôt ne coûte rien.

Travailler dans un endroit réversible

Tout ce qui est modifié doit pouvoir se défaire :

• le code sur une branche, que je relis avant de fusionner ;
• les contenus du CMS en brouillon, jamais publiés directement ;
• les tickets commentés plutôt que fermés, tant que je n’ai pas vérifié.

Demander un compte rendu

À la fin, je demande un résumé court : ce qu’il a lu, ce qu’il a modifié, ce qu’il n’a pas pu faire. C’est ce résumé que je relis en premier, puis le diff. Si le compte rendu et le diff ne racontent pas la même histoire, je creuse.

Pour ne pas réécrire la consigne à chaque fois, je garde un fichier consigne-mcp.md à la racine du projet. Je le colle en début de tâche, je remplis les trois premières lignes, et l’assistant sait déjà ce que j’attends de lui à chaque étape. Le voici, à copier tel quel :

# Tâche
Objectif : [le résultat attendu, en une phrase]
Outils : [ex. Figma en lecture, Linear en commentaire]
Périmètre : [fichier Figma, équipe Linear, dossier du code]

# Règles
- Commence par un plan : ce que tu vas lire,
  ce que tu vas modifier, dans quel ordre.
  N’écris rien avant que je l’aie validé.
- Avance étape par étape, et attends-moi
  après chaque étape.
- Lecture seule par défaut. Annonce toute action
  qui crée, modifie, publie ou supprime.
- Travaille sur une branche, en brouillon dans
  le CMS, en commentaire dans les tickets.
- S’il manque une information, dis-le
  au lieu de deviner.

# Livrables attendus
1. Le plan validé, en quelques lignes.
2. La liste de ce qui a été touché (fichiers,
   contenus, tickets), avec un lien pour chacun.
3. Un compte rendu en trois parties :
   - Lu : frames, tickets, retours, pages consultés.
   - Modifié : ce qui a changé, et pourquoi.
   - Pas fait : ce qui reste, ce qui a bloqué,
     les questions ouvertes.
4. Comment vérifier : les étapes pour tester
   moi-même (page, appareil, cas limites).

Les livrables en fin de fichier font toute la différence : l’assistant sait dès le départ qu’il devra rendre des comptes, et il travaille de façon plus traçable.

Quand la routine est rodée, en faire un skill

Au bout de quelques semaines, certaines tâches se répètent à l’identique : traiter les retours Feedbucket d’un site en recette, préparer les textes alternatifs d’une collection, passer une frame Figma en composant. À chaque fois, je recolle la même consigne, je rappelle les mêmes règles, je redonne les mêmes exemples.

C’est le signe qu’il faut en faire un skill. Un skill, c’est une consigne enregistrée une fois pour toutes : un fichier d’instructions, éventuellement accompagné d’exemples ou de modèles, que Claude charge tout seul quand la tâche s’y prête. Le fichier consigne-mcp.md de plus haut est un très bon point de départ.

Dans l’application, le bouton Ajouter propose trois façons de faire : importer un skill déjà prêt, l’écrire soi-même, ou le construire en discutant avec Claude. La troisième est la plus simple pour commencer : je décris la routine telle que je la fais, Claude pose ses questions et rédige le skill, je relis et j’ajuste.

Ce que je mets dans un skill :

• Quand l’utiliser. Une phrase claire, pour que Claude le déclenche au bon moment et pas ailleurs.
• Les étapes, dans l’ordre, avec les arrêts où j’attends de valider.
• Les outils MCP concernés, et ce qu’il a le droit de faire avec chacun.
• Les livrables attendus, au même format à chaque fois.
• Un ou deux exemples réels, un bon et un raté, pour montrer la différence.

Ce qui coince

Tout n’est pas fluide, et les promesses faciles autour de l’IA m’agacent autant que n’importe qui.

• Trop d’outils branchés, c’est du bruit. Avec quinze serveurs actifs, l’assistant hésite, choisit la mauvaise action ou charge du contexte pour rien. Je garde actifs ceux du projet en cours.
• Les droits en écriture font peur, à raison. Je commence toujours en lecture seule. L’écriture vient après, outil par outil, quand j’ai vu comment il s’en sert.
• Le résultat se relit. Un ticket mal résumé ou une variable mal lue, ça arrive. C’est le travail d’un collègue rapide, pas celui d’un collègue fiable à 100 %.
• Certains serveurs sont jeunes. Des actions manquent, d’autres changent d’une version à l’autre. Il faut accepter de bricoler un peu.

Par où commencer

Le plus simple est de partir d’une tâche que vous faites chaque semaine et qui vous ennuie.

1. Repérez l’outil où vous recopiez le plus d’informations.
2. Branchez seulement celui-là, et lisez la liste de ses outils.
3. Désactivez ce qui écrit, et validez chaque action à la main.
4. Faites la tâche avec l’assistant pendant deux semaines, plan d’abord, en relisant tout.
5. Si ça tient, ouvrez l’écriture, outil par outil. Sinon, débranchez sans regret.
6. Quand la routine est rodée, transformez-la en skill.

Je n’ai pas « automatisé mon workflow ». J’ai arrêté de faire le facteur entre mes onglets, et ce temps-là, je le passe sur ce qui compte : regarder le rendu, ajuster, décider.