MCP : qu’est-ce qui change quand c’est toi qui orchestres ?

L’IA me répondait, maintenant elle travaille dans mon environnement.

Pendant longtemps, ma collaboration avec l’IA ressemblait peu ou prou à la même séquence : ouvrir un onglet, écrire un prompt, lire la réponse, puis fermer l’onglet. Utile, certes, mais fondamentalement déconnecté de mon environnement de travail réel. L’IA ne savait rien de mes fichiers Figma, rien de mon calendrier, rien des décisions prises la semaine d’avant, et je devais lui reconstruire le contexte à chaque nouvelle conversation, comme si elle souffrait d’une amnésie permanente.

Depuis que j’utilise MCP, d’abord prudemment, puis de façon de plus en plus intégrée à mon quotidien, quelque chose de fondamental a changé dans cette dynamique. Ce n’est plus moi qui amène le contexte à l’IA. C’est l’IA qui va le chercher là où il vit, c’est-à-dire directement dans mes outils.

Ce glissement peut sembler purement technique en surface, mais il ne l’est pas. Il touche directement à la façon dont je prends des décisions produit, dont je mène des audits design, dont je prépare mes livraisons clients. Et c’est précisément de ça que je veux parler ici : non pas du protocole en lui-même, que Nolwen a déjà très bien expliqué dans cet article, mais de ce que ça change concrètement quand c’est un PM ou un designer freelance qui tient les rênes.

Le vrai changement : passer de « l’IA qui répond » à « l’IA qui agit dans mon flow »

Il y a une distinction que je trouve souvent sous-estimée dans les discussions autour de MCP, à savoir la différence entre un assistant qui répond à des questions et un agent qui opère réellement dans ton environnement de travail. Avant MCP, l’IA était une ressource consultative : je lui soumettais un problème, elle me donnait une réponse. C’est déjà puissant en soi, mais le contexte manquant créait une friction constante, celle d’expliquer le projet, de coller les specs, de résumer l’historique. On perdait facilement la moitié de l’échange à poser le décor avant même de commencer à travailler.

Avec MCP, le décor est déjà là. L’agent peut le lire directement dans mes outils, ce qui change profondément mon rôle dans l’échange : je ne suis plus celui qui amène l’information, je suis celui qui formule l’intention et qui valide l’output. C’est ça, orchestrer. Pas coder ni configurer à longueur de journée, mais bien plus encore : décider ce qu’on demande, à quel moment, et avec quel niveau de confiance on valide le résultat.

Un exemple concret : MCP avec Figma

Le cas qui m’a le plus convaincue est celui de l’audit de composants. Sur un projet récent, je travaillais sur un design system qui avait accumulé des incohérences sur plusieurs mois, le genre de situation où chaque sprint a laissé sa petite trace et où plus personne n’a vraiment une vision globale de l’état du fichier. Avant d’avoir Figma MCP connecté à Claude Desktop, un audit de ce type prenait une demi-journée entière : ouvrir chaque frame, noter les écarts manuellement, puis produire un tableau de synthèse.

Avec la connexion MCP en place, j’ai pu demander directement à l’agent de parcourir le fichier et d’identifier les composants dont le padding interne n’était pas aligné sur notre système de 8px. Il navigue dans le fichier, remonte les incohérences, et me produit une liste structurée, ce qui me laisse uniquement la relecture à faire plutôt que toute la collecte d’information.

Mais ce qui m’intéresse le plus dans cette configuration, ce n’est pas le gain de temps brut en lui-même. C’est la qualité de la conversation design qui devient possible ensuite. Parce que l’agent a accès au fichier réel, on peut raisonner sur la cohérence systémique, comparer des états de composants, anticiper des problèmes d’implémentation, et tout ça avec le fichier comme référence partagée plutôt qu’une description approximative collée à la main dans un prompt. Pour un PM ou un designer qui jongle constamment entre la vision produit et l’exécution, c’est un levier considérable.

Google Calendar et Gmail : l’IA qui comprend mon rythme de travail

L’autre connexion que j’utilise régulièrement est Calendar et Gmail via MCP. Moins spectaculaire que Figma au premier abord, mais c’est probablement celle qui a le plus changé ma façon de structurer mes semaines, justement parce qu’elle agit sur des micro-frictions très fréquentes plutôt que sur des tâches ponctuelles.

Exemple typique : j’ai une réunion de suivi projet dans deux heures et je veux préparer un point de situation rapide. Avant, j’ouvrais mes notes, mes derniers échanges mail, le doc de specs, et j’assemblais mentalement l’ensemble. Maintenant, je demande à l’agent de consulter les derniers échanges liés au projet, de regarder ce qui était prévu à l’ordre du jour de la réunion précédente, et de me synthétiser les points encore ouverts. Il arrive dans ma réunion avec moi, en quelque sorte.

Ce que ça révèle au fond, c’est que la valeur de MCP pour un freelance ne tient pas à la sophistication technique de la connexion. Elle tient à la suppression progressive de ces micro-frictions qui s’accumulent : les cinq minutes perdues à retrouver un email, les dix minutes à récapituler le contexte d’un projet qu’on n’a pas touché depuis trois jours. Individuellement, ce sont des broutilles, mais cumulées sur une semaine de multi-projets, elles représentent une charge cognitive réelle qui, une fois soulagée, libère de l’espace pour ce qui compte vraiment.

Ce que l’orchestration demande vraiment

Je veux être honnête sur un point qui est souvent passé sous silence : orchestrer des agents MCP, ça s’apprend. Non pas au sens technique du terme, car la configuration reste relativement accessible, mais au sens du jugement que ça demande de développer progressivement.

Il faut construire l’intuition de savoir quand déléguer à un agent et quand rester en mode manuel. Toutes les tâches ne se prêtent pas à l’orchestration, et sur les sujets sensibles, les arbitrages stratégiques ou les conversations client à enjeu, je garde systématiquement la main. L’agent peut préparer et synthétiser, mais il ne décide pas à ma place.

Il faut aussi apprendre à formuler des intentions claires sans pour autant tout sur-spécifier. Les meilleurs prompts que j’ai écrits dans ce contexte ne sont pas les plus détaillés : ce sont ceux qui donnent un objectif précis et laissent l’agent choisir ses chemins dans les outils connectés. Enfin, il faut accepter une phase de calibration. Les premières semaines, j’ai eu des outputs décevants, des interprétations trop larges, des moments où l’agent consultait les mauvaises ressources. C’est normal et ça s’affine avec l’usage, exactement comme n’importe quel outil de travail.

Pourquoi ce rôle est naturel pour un PM ou un designer

Ce qui me frappe de plus en plus, c’est à quel point le profil PM ou designer est bien positionné pour tirer le meilleur de MCP, probablement mieux que beaucoup de profils purement techniques d’ailleurs. On est formés à penser en flux, en parcours, en enchaînements logiques. On sait décomposer un problème complexe en étapes actionnables. On a l’habitude de travailler avec des outils multiples et de faire circuler l’information entre eux. Et surtout, on est habitués à articuler des intentions précises, ce qui est exactement ce que demande l’orchestration d’agents.

Le PM qui écrit de bons tickets sait formuler une intention précise avec un périmètre défini. Le designer qui rédige de bonnes specs sait décrire un état attendu sans prescrire chaque détail d’implémentation. Ces compétences, directement transférables à la construction de workflows agentiques, étaient déjà là bien avant que MCP n’existe. En ce sens, MCP ne crée pas un nouveau métier. Il révèle une compétence qui existait déjà sous une autre forme.

Pour finir

Je ne prétends pas que MCP est indispensable dès maintenant pour tout le monde. L’écosystème est encore en construction, certains serveurs sont plus robustes que d’autres, et il faut rester vigilant sur les permissions qu’on accorde, surtout dans un contexte professionnel avec des données sensibles.

Mais si tu es PM ou designer freelance et que tu travailles déjà avec Claude ou un équivalent au quotidien, la question n’est plus vraiment de savoir si tu devrais regarder MCP. Elle est plutôt de déterminer quel est le premier flux de travail dans ta semaine où tu gagnerais vraiment à connecter tes outils. Pour moi, c’était Figma. Pour toi, ce sera peut-être autre chose, mais il y a très probablement un premier cas d’usage quelque part qui mérite qu’on lui pose la question.