[Décryptage] MCP & Vibe Coding : Le futur du produit à l'ère de l'IA
"Le train de l'IA est déjà parti, j'ai peur d'arriver trop tard." Cette petite voix, beaucoup de Product Managers l'entendent. On se sent dépassé par la vitesse à laquelle les technologies comme les Large Language Model (LLM) évoluent, et l'idée de "mettre de l'IA" dans son produit a l’air insurmontable.
Pourtant, lors de notre dernier We.Talk, Frédéric Bardolle, Head of AI Product chez Scaleway, a apporté une approche rafraîchissante : le futur du produit est dans l'action et l'expérimentation rapide. Il a partagé deux concepts clés qui changent la donne : les Model Context Protocol(MCP) pour connecter nos produits au monde, et le Vibe Coding pour passer de l'idée au prototype en quelques minutes.
Voici le décryptage de ces deux approches pour que tu puisses, toi aussi, te lancer sans crainte.
Framework 1 : Les MCP, ou comment donner des super-pouvoirs à ton produit
Le problème de base est simple : un LLM, aussi intelligent soit-il, est enfermé dans une boîte. Il génère du texte, mais ne peut pas interagir avec le monde réel. Demande-lui "d'éteindre la lampe de mon salon", et il te répondra poliment qu'il n'a pas de bras.
C'est là que le MCP entre en jeu.
Imagine le MCP comme une multiprise qui permet de brancher ton application IA avec n'importe quel outil externe (une API météo, une base de données, un service de réservation...). Plutôt que de devoir coder 10 connecteurs complexes pour 10 outils différents, ton produit dialogue avec des serveurs MCPs disponibles et faciles à intégrer, faisant le lien avec tes outils.
Schéma d’un protocole MCP à travers l’exemple de ChatGPT et de deux applications tierces (Gmail & Notion)
Concrètement, ça change quoi pour toi, PM ?
Ton produit fournit des services : Tu peux créer ton propre serveur MCP. D'un coup, ton produit devient "compatible" avec des milliers d'agents IA. Ainsi, il devient possible de demander à une IA de faire des actions sur ton produit en langage naturel ;
Tu veux enrichir ton produit d’autres services : Tu veux que ton produit IA s'enrichisse en utilisant des outils externes ? En te connectant à des MCP existants, tu donnes à ton produit un accès direct à une multitude de services (météo, réservation, paiement...) sans avoir à développer chaque connecteur.
Le MCP, c'est la promesse d'un produit qui ne vit plus en silo, mais qui devient une pièce d'un écosystème intelligent et connecté.
⚠️ Un point de vigilance sur la sécurité
Il existe un répertoire sur GitHub qui liste de nombreux serveurs MCP disponibles. C'est une super ressource, mais fais très attention : donner tes clés API à un MCP, c'est comme donner les clés de ta maison à un inconnu.
Avant de connecter quoi que ce soit, vérifie toujours qui a créé le MCP : est-ce l'entreprise officielle ou un utilisateur tiers ? Ne donne jamais de droits sensibles sans être absolument certain de la fiabilité du créateur.
Une question qui revient souvent : "Est-ce que les MCP vont tuer mes APIs ?" La réponse est non. Les MCP ne remplaceront pas tes APIs : ils agissent simplement comme une couche de 'traduction' permettant aux LLM de se connecter à tes APIs, qui restent indispensables à la communication entre tes systèmes.
Framework 2 : Le Vibe Coding, ou comment prototyper à la vitesse de la pensée
L'autre grande frustration du PM, c'est le temps qui sépare une idée de sa première version tangible. Entre la rédaction des PRD, les maquettes Figma et le développement, des semaines peuvent s'écouler...
Le Vibe Coding explose ce cycle. Le principe, comme l'a démontré Fred en live, est simple :
Tu ouvres un éditeur de code assisté par IA (comme Cursor, Lovable ou Bolt) ;
Tu décris en langage naturel ce que tu veux construire. Pense features et MVP : commence par la fonctionnalité la plus simple et construis ton produit peu à peu.
Le résultat ? En moins de 20 minutes, Fred est passé d'un dossier vide à une application web fonctionnelle avec une génération d'images et un historique.
🔎 Les coulisses de la démo de Fred : Ce qu'on a vu pendant le talk, c'était l'imbrication de plusieurs technologies :
L'outil (l'IDE) : Cursor, un éditeur de code qui intègre nativement une IA ;
Le "cerveau" (LLM) : le modèle Qwen3-Coder (un LLM spécialisé dans le code), qui interprétait les demandes de Fred et écrivait le code ;
La génération d’image : un service externe d’OpenAI (Dall-E) ;
Le lien : l'IA (Qwen) a écrit du code qui appelle directement l'API d'OpenAI pour générer les images Pokémon.
Si toi aussi tu veux te lancer, voici quelques conseils pour aller plus loin
Valide les actions de l'IA étape par étape. Si tu veux faire quelque chose de complexe, itère ! Ajoute les fonctions les unes après les autres ;
Demande explicitement à l'IA d'intégrer des boucles de tests pour s'assurer que le code est fonctionnel, et de versionner son code pour pouvoir revenir en arrière si besoin et ne pas perdre ton travail.
A noter que ce code n'ira jamais en production. Son but est ailleurs :
Valider la faisabilité : En quelques minutes, tu sais si ton idée est techniquement réalisable ;
Créer un artefact tangible : Fini les longs discours. Tu peux mettre un prototype qui "marche" entre les mains d'un utilisateur ou d'un stakeholder pour obtenir des retours immédiats ;
Mettre les mains dans le cambouis : C'est un moyen incroyable d'apprendre les bases du code et de mieux comprendre le fonctionnement de ton produit "sous le capot".
Le Vibe Coding, c'est l'outil ultime pour réduire drastiquement le cycle de la Discovery et tester plus d'idées, plus vite.
💡 Le Regard de Nos Experts : L'avis de Tristan Marchal, Consultant PM Senior WeFiiT
Le Vibe Coding peut faire peur au début, mais c'est une compétence qui va devenir essentielle pour les Product People. Voici comment te lancer sans te sentir dépassé :
Le bon point de départ ? L'outil n'est pas le plus important. Que ce soit Lovable, Bolt, Cursor ou un autre, le principal au démarrage est de te familiariser avec l'un d'eux. Lance-toi, construis un petit projet, et touche les limites du doigt. C'est en pratiquant que tu comprendras la puissance et les contraintes de ces outils.
Le principal piège à éviter ? Changer ta méthodologie produit ! Le Vibe Coding ne remplace pas la Discovery, il la suralimente. C'est un outil qui s'intègre dans tes rituels existants sans les supprimer. Pense à la boucle "Build-Measure-Learn" : le Vibe Coding te permet de faire le "Build" (construire un prototype) en quelques minutes au lieu de quelques semaines. Mais ça ne te dispense pas de savoir POURQUOI tu construis (le problème utilisateur), ni de faire le "Measure" et le "Learn" (tester ton prototype avec de vrais utilisateurs pour valider ou invalider tes hypothèses).
Quelle est la question la plus importante à se poser ? Après avoir généré ton proto, la question n'est pas "le code est-il propre ?", mais "Est-ce que cet artefact me permet de tester mon hypothèse utilisateur plus rapidement qu'avant ?". Le vibe coding reste une pratique de Discovery, pas de Delivery.
