Voilà comment j’utilise vraiment les MCP au quotidien (et pourquoi je fais gaffe à ne pas en abuser)

On entend beaucoup parler de MCP, d’agents, d’IA, d’“agentic workflows”, etc.

Le problème, c’est que beaucoup en parlent, peu en utilisent vraiment, et encore moins arrivent à en tirer un impact concret au quotidien.

Le schéma classique que je vois partout :

• on crée un agent,

• on lui connecte 12 outils,

• on lui ajoute 4 bases de connaissances,

• et à la fin… c’est indigeste.

Pourquoi ? Parce que les LLM d’aujourd’hui ne sont pas magiques :

plus tu ajoutes de contexte et d’outils, plus tu augmentes la confusion, le coût en tokens, et le risque de “faire n’importe quoi”.

Moi, j’utilise les MCP tous les jours.

Mais je les utilise comme des accélérateurs ciblés, pas comme un sapin de Noël.

Je te détaille comment, concrètement.

1. Sur Cursor : le MCP “documentation”, c’est la base

Sur Cursor, pour tout ce qui est dev (framework, lib, SDK), j’ai un réflexe simple :

Si j’utilise un framework ou une techno X ou Y, je regarde si la doc est dispo en MCP.

Pourquoi ? Parce que ça change la dynamique.

• Cursor peut vérifier une info au lieu d’halluciner.

• Il peut aller chercher la bonne version de la doc.

• Et surtout, ça me fait gagner un temps énorme sur les allers-retours “attends, c’est quoi déjà la bonne option / le bon paramètre / la bonne syntaxe”.

C’est un usage très simple, très “bête”, mais ultra rentable :

je ne demande pas à l’agent de réfléchir mieux, je lui donne la possibilité de vérifier.

Exemple avec la documentation de langchain :

{
  "mcpServers": {
    "docs-langchain": {
      "url": "<https://docs.langchain.com/mcp>"
    }
  }
}

2. Toujours dans Cursor : le MCP Supabase = game changer (surtout au lancement)

Le deuxième MCP que j’utilise énormément, c’est Supabase.

Pourquoi ? Parce que sur un lancement de produit, il y a toujours le même mur :

• architecture de base de données,

• migrations,

• tables,

• relations,

• et surtout… RLS policies.

Et là, le MCP Supabase, pour moi, c’est un vrai game changer.

Ce que ça m’apporte :

• aller vite sur la structure DB,

• être beaucoup plus confiant sur la sécurité (RLS),

• itérer rapidement sans passer 2h à relire la doc / vérifier les patterns.

En gros : ça raccourcit les “phases chiantes”, celles qui prennent du temps, mais qui sont non négociables si tu veux un produit propre.

{
  "mcpServers": {
    "supabase": {
      "url": "<https://mcp.supabase.com/mcp?project_ref={VOTRE_ID_PROJET}>",
    }
  }
}

3. Côté “Cloud chat” (pas Cursor) : j’utilise les MCP différemment

Ensuite, j’ai tout un autre usage des MCP dans une interface de chat type “Cloud” (pas dans Cursor).

Là, l’objectif n’est pas de coder vite.

C’est plutôt de :

• brainstormer,

• structurer,

• orchestrer,

• et préparer un projet proprement (instructions, contexte, docs, repo).

Le MCP Notion : je l’ai testé, mais ce n’est pas celui que j’aime le plus

Notion, sur le papier, c’est génial.

En pratique, le MCP Notion a un problème : il a énormément de fonctions et la navigation interne peut devenir pénible (IDs, bases, structure, etc.).

Même si ton Notion est bien organisé, l’agent peut galérer à “se repérer” dedans.

Donc : je ne dis pas que c’est nul.

Je dis juste que dans mon usage, ce n’est pas celui qui m’a donné le meilleur ROI.

Le MCP Google Workspace : là, par contre, c’est une évidence

Google Workspace, c’est l’exemple parfait d’un MCP qui apporte un bénéfice immédiat. Je l’utilise principalement aujourd’hui pour mes emails et la gestion de mon agenda (pro comme perso).

Ce sont des use case assez simple : “Peux tu regarder si X m’a répondu”, “Prépare une réponse à mon comptable en allant regarder tel document dans drive” … “Planifie une réunion avec Hugo demain a 10h pour parler de tel sujet”….

Le gain de temps n’est pas flagrant, mais la simplicité de le faire depuis une app mobile en vocal c’est ca qui m’aide vraiment.

4. Mon “super agent” interne : plein de MCP, mais avec orchestration intelligente

À côté de ça, j’ai développé une petite app custom pour piloter mon agence.

Dedans, j’ai connecté :

• Facebook Ads MCP

• Google Ads MCP

• Google Agenda MCP

• Supabase MCP

• Xero (notre “petit comptable”)

• Figma MCP

• etc.

Oui, ça fait beaucoup.

Et justement : si tu fais ça “bêtement”, tu te retrouves avec un agent ingérable :

• trop d’outils,

• trop de choix,

• trop de contexte,

• trop de tokens,

• et au final : pas fiable.

Donc la clé, c’est pas “connecter plus”.

La clé, c’est orchestrer mieux.

Mon app, ce n’est pas juste un agent.

C’est un agent avec un système qui décide quoi appeler, quand, et pourquoi, en fonction du prompt.

Objectif :

• éviter les fenêtres contextuelles énormes,

• éviter les comportements erratiques,

• garder des coûts raisonnables,

• et surtout : avoir un truc qui marche vraiment.

Si tu veux le détail technique, j’ai déjà écrit un article sur l’architecture HBT (MacOS + iOS) où j’explique comment on structure le raisonnement et l’orchestration pour gérer beaucoup de MCP sans exploser les tokens.

C’est disponible ici

5. Le “combo” que j’utilise quand je démarre un nouveau projet

Quand je commence un nouveau projet, ma routine est assez stable :

1. je crée le projet + mes instructions système (le cadre)

2. si besoin, je connecte le repo GitHub dans l’interface de chat

3. je connecte les docs via MCP quand elles existent (Stripe typiquement, ou d’autres SDK)

4. et là je brainstorm : architecture, approche, étapes, choix techniques

Ce que j’aime dans cette phase :

• tu poses les fondations vite,

• tu réduis les erreurs de doc,

• tu évites les “on verra plus tard”

• et tu arrives au dev avec quelque chose de déjà cadré.

6. Le point que personne ne dit : MCP ≠ toujours plus vite

Maintenant, attention.

Les MCP, c’est puissant.

Mais si tu commences à tomber dans :

• des boucles itératives,

• des agents qui te posent 15 questions,

• des workflows où l’IA “cherche” au lieu d’avancer,

…souvent, ça va juste plus vite d’ouvrir l’outil toi-même.

C’est ça, la vraie maturité sur le sujet :

savoir quand l’agent t’accélère, et quand il te ralentit.

Aujourd’hui, j’ai retrouvé une bonne balance :

• MCP pour accélérer les tâches “vérifiables” et structurées,

• orchestration pour les workflows multi-outils,

• et intervention humaine quand c’est plus simple.

Et je continue d’itérer sur mon super agent interne, parce que l’objectif final est clair :

piloter une grosse partie du business depuis mon téléphone ou mon Mac, sans que ça devienne un cirque à tokens.