Tout le monde parle de MCP : Leçons des développeurs chez Miro, Atlassian et au-delà

Vous trouverez ci-dessous une transcription éditée de la conversation. Les citations ont été légèrement condensées pour plus de clarté. 

Les API existent depuis toujours. Qu'est-ce que MCP débloque concrètement que les API ne pouvaient pas faire ?

Gunjan : Par le passé, vous deviez comprendre l'API de chaque outil, consacrer vos ressources de développement déjà limitées à la création de ces différentes intégrations, et si une exigence changeait — par exemple, au lieu de simplement lire quelque chose, vous deviez écrire quelque chose — vous repartiez en arrière pour effectuer la modification et attendiez six semaines. C'était le cycle : c'était lent, et c'était coûteux.

Avec MCP, des serveurs sont fournis par les fournisseurs eux-mêmes, et vous exprimez simplement votre intention. Votre vitesse de développement s'en trouve considérablement accélérée. Vous passez de la définition d'appels spécifiques à une action à la description de ce que vous souhaitez obtenir. C'est là qu'intervient l'orchestration des agents, qui consiste à attribuer concrètement des tâches aux agents, devient possible. Sans cela, c'était tout simplement impossible.

Kosta : Les API connectent les outils, mais quelqu'un doit encore cliquer sur les choses et donner du sens à tout cela. MCP permet aux agents de lire le contexte à travers les outils et d'agir en leur sein, à une échelle qu'aucun individu ne pourrait atteindre.

Qu'avez-vous réellement construit avec MCP, et à quoi cela sert-il ?

Michelle : J'ai créé un système de triage qui connecte le MCP de Pendo avec le reste des données de l'organisation. C'est mon rituel matinal quotidien. Que dois-je savoir avant de parler à qui que ce soit ? Avant de regarder des replays de session, lesquels sont les plus importants ? Que s'est-il passé hier ?

Il me dit ce que certaines personnes ont fait, en fonction d'un groupe que j'ai créé autour de nos responsables de la réussite client. Il signale l'activité standard, les problèmes potentiels à surveiller, les pics de données, les différents volumes à examiner, les succès à célébrer. Je peux également lui demander quelles sessions je devrais regarder avant de contacter des CSM. Il met en évidence des éléments tels que : une consultation intensive du contenu sessions, de nombreux clics rageurs et clics morts, des événements de frustration importants, des utilisateurs avancés dans un flux de création rapide. C'est le briefing matinal d'un directeur produit, conçu dans un agent, exécuté selon un calendrier quotidien.

Kosta : Nous avons injecté la transcription d'un appel de découverte client dans Claude et généré un PRD directement sur le tableau Miro. À partir de là, nous avons cartographié un parcours utilisateur, ajouté des captures d'écran de référence et pris des notes, le tout dans un espace partagé. Une fois l'équipe alignée, j'ai déposé l'URL du tableau dans Claude Code. Le MCP a compris le contexte et généré un prototype fonctionnel qui reflétait ce sur quoi nous nous étions alignés. Nous l'avons présenté aux parties prenantes et validé avec le client le même jour. Il y a un an, ce type de rapidité n'était pas possible. Désormais, n'importe qui peut passer d'un problème client à une solution alignée en quelques heures.

Gunjan : En tant que chefs de produit, nous jonglons avec beaucoup de choses, et l'une des tâches les plus importantes est de savoir ce que les clients demandent : ce qu'ils aiment, ce qu'ils n'aiment pas, comment ils utilisent le produit, et ce qui se passe dans les récentes conversations commerciales. Cette recherche prenait autrefois des heures. J'ai créé un agent dans Rovo. Je lui ai donné accès à mon outil de vente, Google Docs, Calendar, GitHub, les tickets Jira, les pages Confluence, les notes de réunion, les leads Hotspot. Quand je lui demande de m'aider à préparer une réunion à venir, il utilise tous ces outils et produit un rapport complet en quelques minutes. Des tâches qui me prenaient des heures ne prennent plus que quelques minutes, et j'entre dans la salle avec beaucoup plus de confiance.

Qu'avez-vous mal fait lors de la création de votre premier serveur MCP ?

Francois : Nous avons commis une grosse erreur : nous avons exposé les outils comme des primitives de très bas niveau. Ce que nous disions, c'était : si vous avez une question, appelez cet endpoint et transmettez votre question. Si vous voulez reformuler votre question, utilisez cet endpoint pour la reformuler. Le problème, c'est que nous donnions trop de pouvoir au LLM. Alors le modèle était décider quand utiliser quel outil, et en réalité, ils ont tendance à ne pas utiliser un outil. S'ils sont intelligents, ils diront : « Vous savez quoi, je peux comprendre ça par moi-même. »

Par exemple, si vous demandez « montrez-moi mes 10 meilleurs clients », c'est très ambigu. Le LLM trouverait simplement sa propre définition et appellerait Spotter pour obtenir la réponse. Et si vous posiez la même question deux fois, vous pourriez obtenir une réponse différente. Il hallucinait dans le sens où il définirait « meilleur » en fonction de ce qu'il jugeait le plus pertinent pour un ensemble de données bancaires : parfois un compte d'épargne, parfois un compte de crédit. 

Nous fournissons désormais des outils qui intègrent toute l'intelligence en eux-mêmes. Nous ne laissons pas Claude apporter sa propre intelligence, car nous connaissons nos données et nous disposons de plus de contexte que le modèle. Nous le contrôlons via notre couche sémantique, de sorte que chaque fois que vous posez une question, vous obtenez la même réponse, ancrée dans tout le contexte dont nous disposons.

Michelle : C'est exactement pourquoi j'ai utilisé toutes les requêtes SQL dans ma couche d'instructions. Ce sont les définitions. C'est ce que signifie être « top » dans nos données. Les personnes qui effectuent des requêtes ne savent pas toujours quel mot exact utiliser ou quel est le nom du champ, donc ce niveau d'explication était nécessaire pour nos données internes.

Comment avez-vous décidé ce qu'il fallait exposer en premier — et comment décidez-vous ce qu'il ne faut pas exposer ?

Kosta : Ce n'est pas une solution universelle. Chez Miro, nous avons commencé par des cas d'usage validés et avons stratégiquement réduit le champ de ce sur quoi nous voulions nous concentrer. Lorsque nous avons construit le serveur MCP, ce sont vraiment les ingénieurs qui l'ont adopté en premier. Nous avons donc construit autour des flux de travail d'ingénierie, en particulier le problème des agents qui écrivent des milliers de lignes de code et la difficulté de visualiser ce qu'ils font pour les orienter. Nous nous sommes concentrés là-dessus, et sur la façon de prendre l'intention de l'équipe et de la transmettre à la génération de code. Cela nous a empêchés d'aller trop large trop tôt, ce qui aurait semé la confusion à la fois chez les agents et dans notre discours commercial.

Michelle : Nous avons commencé avec un seul agent et avons progressé à partir de là. Nous avons également commencé par ce qui était le plus simple et le plus fiable. Nous voulions nous assurer que les utilisateurs faisaient confiance à l'outil avant de dire « nous allons gérer cela de bout en bout pour vous. » Nous voulons que l'utilisateur reste aux commandes, avec des garde-fous en place, avant de dire que nous pouvons gérer toutes ces tâches automatiquement. C'est ainsi que s'est déroulé le processus de croissance lente.

Francois : Vous devez vraiment réfléchir à l'endroit où vous souhaitez exploiter l'intelligence. Voulez-vous déléguer au LLM ? Dans certains cas, c'est parfait. Mais dans notre cas, comme les données sont très sensibles, nous avons dû concevoir les choses autrement. C'est bien plus que le MCP en soi. Il s'agit vraiment d'intégrer la dimension agentique.

Quant à ce qu'il ne faut pas exposer, cela revient à votre couche sémantique. C'est là que vous spécifiez quelles tables vous souhaitez exposer, qui a le droit de faire quoi. Dans l'ancien monde, le tableau de bord était le garde-fou. Un analyste contrôlait quelles visualisations figuraient sur le tableau de bord. Maintenant que les tableaux de bord disparaissent et que les gens veulent s'adresser directement à la data, la couche sémantique devient le nouveau point de contrôle.

Comment amener votre équipe à changer réellement sa façon de travailler ?

Kosta : Cela se résume à deux choses. La première est le mandat : ce n'est même pas uniquement ma décision. La direction de l'entreprise doit décider que c'est important. Chez Miro, il est largement admis que nous voulons accélérer l'adoption, surtout compte tenu de la rapidité avec laquelle le marché évolue. Mais le mandat seul ne suffit pas. Nous investissons donc également beaucoup dans l'accompagnement. Nous ont des AI Product Guilds, des canaux Slack où les gens peuvent apprendre les uns des autres, des sessions en direct. En tant que leaders, nous devons également montrer l'exemple. Je vais coder un prototype en mode vibe et en discuter avec mes collaborateurs directs. Ils s'inspirent — et souvent, ce sont eux qui m'inspirent. Ils sont proches du terrain. Ils construisent des choses vraiment incroyables.

Gunjan : Nous devons vraiment donner leur chance à ces outils. Expliquer ce que nous voulons qu'ils fassent et croire qu'ils y arriveront. Les modèles d'aujourd'hui n'y parviendront peut-être pas entièrement, mais ceux de demain y parviendront certainement. Donc un acte de foi, essayer sans viser la perfection, c'était l'objectif. Et il faut continuer à revenir et à essayer. Aujourd'hui, Claude Code est vraiment performant. Demain, quelque chose d'autre pourrait être meilleur. Tous les six mois, revenez tester ces outils, car ils ont peut-être débloqué des fonctionnalités qu'ils ne pouvaient pas offrir auparavant.

À quoi ressemble le succès pour vos outils MCP ? Quel est l'indicateur clé ?

Gunjan : Très bientôt, je pense que nous cesserons de faire la distinction entre un utilisateur humain et un utilisateur IA. Il s'agit avant tout de flux de travail. Combien vous en alimentez, et à quelle vitesse ils s'accélèrent. Une équipe qui traite 100 tickets et organise cinq scrums par mois, avec des agents qui rédigent 100 PR chaque jour, voudra probablement tenir un scrum quotidien pour gérer et contrôler ce qui se passe. Votre KPI devient : le nombre de workflows orchestrés dans vos systèmes, indépendamment de l'endroit où se trouve le front-end de cette expérience.

Kosta : Nous l'abordons comme n'importe quel autre produit. Nous observons une croissance non linéaire de l'adoption du MCP, tant en termes de nombre d'utilisateurs que de fréquence d'utilisation. Mais nous cherchons vraiment à comprendre les flux de travail. À quoi les gens l'utilisent-ils ? Rencontrent-ils du succès ? Y reviennent-ils pour ces mêmes flux de travail ? Nous constatons une vraie fidélisation maintenant, notamment avec des fonctionnalités comme la visualisation de code. Nous continuons à observer comment les gens utilisent Miro dans l'ensemble, pas seulement MCP. C'est les deux.

Si les utilisateurs tirent de la valeur de votre produit sans jamais ouvrir votre interface, qu'est-ce que cela signifie pour votre activité ?

Kosta : Je renverserais la question. Si les agents font le travail, où les équipes vont-elles pour les comprendre et les piloter ? La plupart des outils d'IA sont une boîte noire. Nous réfléchissons beaucoup à l'endroit où vous allez pour aligner ces agents, comment vous vous assurez qu'ils font ce qu'il faut. Pour nous, c'est une opportunité, pas une menace. Miro a été conçu pour la collaboration en équipe. C'est ne change pas. L'équipe vient de s'agrandir.

Gunjan : Votre avantage concurrentiel, c'est ce que vous construisez. Si quelqu'un d'autre peut reconstruire votre produit plus vite que vous ne pouvez le défendre, alors oui, reconsidérez la question. Mais si vous pouvez miser davantage sur votre avantage et dire « voilà pourquoi les gens utilisent notre produit et voilà le meilleur résultat pour eux », vous pouvez vraiment vous concentrer. Être obsédé par le client vous donne le droit de demander vos clients à rester avec vous. S'ils sont satisfaits de ce que vous leur proposez, ils le feront.

Francois: Pour nous, en tant qu'outil d'analyse, l'expérience utilisateur est primordiale. Vous devez pouvoir explorer en profondeur, visualiser, modifier des éléments. Ce qui est bien avec les applications MCP, c'est que vous n'avez plus à choisir. Les utilisateurs avancés peuvent toujours aller loin dans le produit. Les utilisateurs métier peuvent poser une question et obtenir un graphique directement dans leur agent. C'est la coexistence, pas la compétition.

Comment la fonction de gestion de produit évolue-t-elle réellement ?

Michelle : J'adorerais arrêter d'écrire des stories Jira — et en fait, l'IA en écrit beaucoup pour moi maintenant. Mais il faut toujours le cerveau. Ce qui s'améliore : moins de retravail, moins de bugs, parce que le contexte est conservé et ce que vous aviez manqué la dernière fois, vous ne le manquerez pas la prochaine fois. Nous ne passons plus autant de temps sur les spikes. Combien de temps avons-nous passé lire la documentation API pour savoir si quelque chose était même possible ? En cinq minutes, vous pouvez obtenir cette réponse. Plus besoin de spikes.

Kosta : Les agents prennent en charge de plus en plus l'exécution et le travail de détail. Mais le véritable métier de chef de produit — la définition du problème, l'alignement, la communication — est plus important que jamais. On ne veut pas que les agents fassent n'importe quoi et décident de ce qu'il faut construire. Personne ne veut ce monde-là. Les personnes en charge des produits doivent donc s'impliquer davantage, réfléchir plus à la craft : cadrage du problème, curation du contexte. Le rôle évolue en s'éloignant de l'exécution pour se concentrer sur des activités à plus fort levier.

Gunjan : Les barrières qui freinaient les gens auparavant : « Je ne sais pas coder », « Je ne comprends pas la syntaxe », tout cela a disparu. Donc l'identification des problèmes est un enjeu majeur dans cette nouvelle ère. Relier les points est également essentiel. L'IA ne va pas relier les points à votre place. Vous devez voir quel problème résoudre, quel problème existe. Et le discernement est un très difficile à acquérir, et cela n'a pas changé. Peu importe les technologies qui vont et viennent. Passer du temps à comprendre ce qu'est la qualité, dans une expérience ou un produit, c'est toujours très important.

Prêt à démarrer avec Pendo MCP ? Consultez notre bibliothèque de prompts, et commencez gratuitement.