Il y a quelques mois encore, j’utilisais l’IA comme un simple assistant : un super moteur de recherche ou un générateur de snippets. Mais les choses ont changé. Vite.
Aujourd’hui, je ne « chat » plus vraiment avec mon IDE. Je collabore avec des Agents.
Récemment, VSCode (ou Cursor si vous voulez) a intégré nativement la gestion des agents. Couplé à des modèles de raisonnement comme Claude Sonnet 4.5 ou Gemini Pro 3, et à la puissance des MCP (Model Context Protocol), ma façon de développer une application, de l’idée au déploiement, a été totalement transformée.
Voici comment je développe mes applications aujourd’hui, étape par étape, sans jamais quitter mon éditeur.
Using agents in Visual Studio Code
Le Setup : Donner des super-pouvoirs à l’IA
Avant d’écrire la moindre ligne de code, il faut équiper l’agent. Un modèle d’IA, aussi puissant soit-il, est limité par sa date de connaissance (training cut-off) et son isolement. Pour pallier cela, j’installe des MCP (Model Context Protocol).
C’est le standard qui permet à l’IA de se connecter à des outils externes. J’en utilise principalement deux :
- Context7 : C’est mon « bridge » vers la connaissance temps réel. Il permet à l’agent de consulter les documentations officielles les plus récentes. Fini le code React déprécié ou les hallucinations sur des API qui n’existent plus.
- ChromeDevTools : Permet à l’agent de « voir » et debugger ce qui se passe dans le navigateur via la console ou des screenshots qu’il prend lui même.
- Supabase, Stripe, MongoDB : J’utilise Supabase pour plusieur de mes projets, un MCP existe permettant aux agents de l’utiliser « nativement ». C’est la même chose avec pas mal de technologies actuelles, je vous invite à les utiliser selon les projets, vos agents n’en seront que plus efficaces !
La Mémoire du Projet : Le dossier .github/instructions
C’est mon secret pour éviter que l’IA ne devienne amnésique ou incohérente au bout de 30 messages.
L’IA a une fenêtre de contexte limitée. Plutôt que de répéter « N’oublie pas qu’on utilise Tailwind » à chaque prompt, je crée un dossier .github/instructions à la racine de mon projet. Les agents VSCode lisent ces fichiers systématiquement avant de répondre.
J’y place généralement :
tech_stack.md: La liste de mes technos (Next.js, Supabase, Shadcn/ui…).- arch.md : L’architecture du projet (les connexions avec les APIs, les dossiers du projets, …)
project_rules.md: Mes principes de design (DRY, composition over inheritance, gestion des erreurs).plan.md: L’état d’avancement(roadmap) du projet (on y reviendra).
C’est la mémoire à long terme de mon assistant.
Phase d’Idéation : Challenger le concept
Tout commence par une discussion, mais pas n’importe laquelle. J’active le modèle Gemini Pro 3, GPT 5.2 ou Claude Opus 4.5 (pour leur capacité de raisonnement supérieure) et je lance un prompt de challenge.
Voici un exemple de prompt :
Objectif : obtenir une analyse complète, structurée et objective d’une idée d’application pour décider de sa viabilité commerciale et stratégique.
Instructions pour l’IA :
Tu es un analyste de marché expert, combinant des compétences en stratégie, business model, étude de concurrence, finance, tarification, estimation des coûts, et validation de produit. Je te fournis ci-dessous une idée d’application ; tu dois évaluer sa viabilité sur le marché réel, en étant objectif et précis.
1. Résumé de l’idée (à remplir)
Nom de l’application :Description succincte :Problème que l’application résout :Public cible :2. Analyse de marché
- Estime la taille du marché adressable (TAM/SAM/SOM) avec des données ou chiffres du secteur (sources publiques, tendances).
- Décris les tendances du marché, croissance, demandes émergentes, et si le problème existe dans la réalité.
- Identifie les indicateurs de demande, comme volume de recherche, communautés/plateformes où le problème est discuté, signaux d’intérêt (forums, social), etc.
3. Concurrence
- Liste les principaux concurrents directs et indirects (produits/services similaires).
- Compare leurs offres, fonctionnalités, positionnement, forces et faiblesses.
- Évalue les barrières à l’entrée (propriété intellectuelle, effets réseaux, coût d’acquisition, licences).
4. Business Model & Tarification
- Propose plusieurs modèles de monétisation plausibles (SaaS, freemium, abonnement, commission, publicité, etc.).
- Pour chaque modèle, suggère plages de prix réalistes basées sur le marché actuel.
- Estime les marges unitaires (par utilisateur/transaction) avec hypothèses de coûts variables et fixes.
5. Coûts & Temps de Développement
- Estime le coût de développement (MVP, version 1) : main-d’œuvre, tech stack, design, tests, infrastructure.
- Donne une plage de durée réaliste de la phase MVP jusqu’à une première version exploitable (en semaines/mois).
- Identifie les ressources ou compétences nécessaires (dev, product, marketing, support).
6. Acquisition & Distribution
- Propose des canaux efficaces pour acquérir les premiers utilisateurs et tester rapidement l’offre (ex. pubs, référencement, réseaux pro, partenariats).
- Estime un coût d’acquisition client (CAC) réaliste selon les canaux.
- Donne une stratégie de go-to-market progressive (phase beta, early adopters, scaling).
7. Scénarios Financiers
- Présente 3 scénarios (pessimiste / réaliste / optimiste) avec :
• Nombre d’utilisateurs sur 12 mois
• Revenus estimés
• Coûts (fixes + variables)
• Point mort financier (break-even)8. Risques & Opportunités
- Identifie risques majeurs (technique, réglementaire, marché, concurrence) et stratégies pour les atténuer.
- Détaille opportunités supplémentaires (extensions de produit, marchés adjacents).
9. Recommandation Finale
- Sur une échelle de 1 à 10, donne une note de viabilité commerciale globale.
- Résume conditions pour poursuivre (ex : validations à faire, données manquantes, prochaines étapes).
Format de réponse attendu :
Réponse structurée par section, avec chiffres ou sources quand c’est possible, hypothèses indiquées clairement, et recommandations concrètes (pas seulement théoriques).L’agent me force à affiner mon tir avant même de coder. Une fois l’idée validée, on passe à la structure.
Planification : Le mode « Plan » de VSCode
Une fois l’idée validée, il va falloir planifier le développement de celle-ci pour en faire une application fonctionnelle (ou dans un premier temps un bon MVP). Pour ça, vous pouvez utiliser le mode « plan » dans VSCode. C’est une fonctionnalité native de VSCode que j’adore. Je ne saute pas dans le code.
Ici, je demande à l’agent de rédiger le PRD (Product Requirements Document). On définit ensemble :
- Le MVP (Minimum Viable Product) : Qu’est-ce qu’on livre en premier ?
- Les User Stories : « En tant qu’utilisateur, je veux… »
- L’Architecture : Base de données, API, Authentification.
L’agent génère un fichier PLAN.md. Ce fichier servira de boussole pour tout le reste du développement. Je le place donc dans mon dossiers « .github/instructions«
Voici un exemple de prompt pour le plan :
Objectif :
Construire un plan global, fonctionnel et non technique d’une application déjà validée sur le marché, décrivant précisément ce que fait l’application, pour qui, et comment les utilisateurs interagissent avec elle, jusqu’à obtenir une vision complète et cohérente du produit.
Rôle de l’IA :
Tu es un Product Manager senior spécialisé en conception d’applications (web / mobile / SaaS).
Ton objectif est de transformer une idée validée en un plan fonctionnel détaillé, clair et structuré, sans écrire de code ni entrer dans des choix techniques.Tu dois :
- Identifier les zones floues ou ambiguës
- Poser des questions ciblées et utiles quand des informations manquent
- Construire le plan progressivement, en itérant avec l’utilisateur
- T’arrêter uniquement lorsque le plan est complet, cohérent et exploitable
1. Contexte de départ (fourni par l’utilisateur)
Nom de l’application :Objectif principal de l’application :Problème utilisateur résolu :Cible principale (utilisateurs) :Plateforme(s) envisagée(s) :(ex : mobile, web, desktop)
2. Méthode de travail (obligatoire)
- Commence par résumer ta compréhension du produit en quelques phrases
- Identifie immédiatement :
- Ce qui est clair
- Ce qui est incomplet ou ambigu
- Pose des questions avant d’aller trop loin si nécessaire
⚠️ Ne fais pas d’hypothèses critiques sans validation.
Pose des questions plutôt que d’inventer.
3. Structure attendue du plan fonctionnel final
Tu devras produire, une fois toutes les informations réunies, un plan contenant au minimum :
A. Vision Produit
- Proposition de valeur principale
- Objectifs du produit (court / moyen terme)
- Règles fondamentales (ce que l’app fait / ne fait pas)
B. Typologie des utilisateurs
- Types d’utilisateurs (ex : visiteurs, utilisateurs inscrits, admins, etc.)
- Droits et capacités de chaque type
- Parcours général de chaque type d’utilisateur
C. Parcours Utilisateur (User Journeys)
- Découverte / arrivée sur l’app
- Inscription / onboarding
- Utilisation principale (cœur de valeur)
- Actions récurrentes
- Sortie / désengagement
D. Fonctionnalités Clés
Pour chaque fonctionnalité :
- Objectif utilisateur
- Description fonctionnelle (ce que ça permet de faire)
- Déclencheur (quand / pourquoi l’utilisateur l’utilise)
- Résultat attendu
⚠️ Pas de technique, pas de code, pas de stack.
E. Règles Métier & Logique Fonctionnelle
- Limitations
- Cas particuliers
- Conditions d’accès à certaines fonctionnalités
- Interactions entre fonctionnalités
F. Gestion des Contenus & Données (fonctionnel)
- Types de données manipulées (sans schéma technique)
- Qui crée quoi, qui voit quoi, qui modifie quoi
- Logique de cycle de vie des contenus
G. Notifications & Interactions
- Types de notifications
- Déclencheurs
- Objectifs (engagement, information, rappel, etc.)
H. Monétisation (si applicable)
- Ce qui est gratuit vs payant
- Déclencheurs de paiement
- Parcours utilisateur lié à la monétisation
I. Administration & Modération
- Fonctionnalités nécessaires pour gérer l’app
- Actions possibles côté admin
- Contrôles et règles
4. Processus itératif obligatoire
- À chaque étape :
- Si une information manque → pose une ou plusieurs questions précises
- Attends la réponse avant de continuer
- Reformule régulièrement pour valider la compréhension
- Ne considère le plan terminé que lorsque toutes les sections sont complètes
5. Critère de fin
Le travail est terminé lorsque :
- Le plan peut servir de base à un cahier des charges fonctionnel
- Un designer ou un développeur peut comprendre ce que doit faire l’application
- Aucune fonctionnalité majeure n’est floue ou implicite
Commence maintenant par :
- Résumer ta compréhension du projet à partir des éléments fournis
- Lister les informations manquantes
- Poser les premières questions nécessaires
Développement : L’Agent aux commandes
C’est ici que la magie opère. Je passe en mode « Agent » avec Claude Sonnet 4.5. Ce modèle est redoutable pour le code.
La règle d’or : Les Micro-tâches
Je ne dis jamais « Crée toute l’application ». C’est le meilleur moyen d’obtenir du code spaghetti.
Je découpe le travail :
« Implémente la User Story #1 : La page de Login avec Supabase Auth. »
Exécution et Auto-correction (Self-Healing)
L’agent va :
- Lire mes instructions (
.github/instructions). - Générer le code des composants.
- Lancer des commandes terminal.
C’est là que c’est fort : si je lui demande de lancer un npm run lint ou un test et que ça échoue, l’agent lit l’erreur et se corrige lui-même. Il itère jusqu’à ce que la tâche soit verte.
Grâce au MCP Context7, s’il a un doute sur une nouvelle fonction de Next.js 16, il va lire la doc officielle avant d’écrire le code, m’évitant des heures de debugging.
Sécuriser l’avancée : Git et Tests
Travailler avec des agents va vite, très vite. Parfois trop. Pour ne pas perdre le contrôle :
- Tests automatisés : J’exige de l’agent qu’il crée un test unitaire pour chaque feature critique. C’est mon filet de sécurité pour m’assurer que les nouvelles modifications ne cassent pas ce qui marchait 5 minutes avant.
- Commit Atomique : Dès qu’une micro-tâche est validée et que les tests passent -> Git Commit.Si l’agent part en vrille à l’étape suivante (ça arrive), je fais un simple rollback. Git est mon bouton « Sauvegarde ».
Déploiement : L’Agent DevOps
Une fois le MVP prêt, je ne change pas de méthode. Je demande à l’agent :
« Prépare le déploiement sur Vercel. Vérifie que les variables d’environnement sont bien configurées dans le projet et génère le Dockerfile si nécessaire. »
L’agent interagit avec les CLI, prépare les configs, et je n’ai plus qu’à valider le push sur GitHub qui déclenchera la CI/CD.
Conclusion
Ce workflow a radicalement changé ma productivité. Je ne tape plus autant de code « boilerplate », mais je passe plus de temps à concevoir, vérifier et guider.
VSCode, avec ses modes natifs (Plan, Agent, Edit) et la puissance des modèles comme Claude Sonnet 4.5, devient plus qu’un éditeur : c’est un véritable cockpit de pilotage.
Et vous, vous avez testé les MCP ? Dites-moi en commentaire quel est votre setup !