Comment livrer un POC en un après-midi : un guide pratique sur Claude Code et Upsun pour les équipes produit et marketing produit

J'ai un projet Upsun qui ne contient que des preuves de concept.

En gros, c’est un tableau de bord. Chaque POC a sa propre vignette. Tu cliques dessus, et tu arrives sur une page avec trois onglets. Le premier onglet contient une explication écrite de ce que le POC démontre. Le deuxième onglet, c’est la démonstration de principe elle-même, avec une démo intégrée qui automatise la présentation des fonctionnalités pour que le destinataire puisse les voir fonctionner sans que je sois en ligne. Le troisième onglet, c’est une liste des éléments de base du produit qui existent déjà pour prendre en charge cette démonstration de principe, plus ceux qu’on devrait créer pour que le produit soit vraiment prêt à être commercialisé.

Je n’ai pas créé le tableau de bord. J’ai demandé à Claude de le faire. Puis j’ai commencé à m’y plonger.

Quand quelqu’un de l’équipe produit ou d’ingénierie veut voir ce à quoi j’ai réfléchi, je lui envoie l’URL du tableau de bord. Il choisit une vignette. La conversation qui s’ensuit est deux fois plus intéressante que celle que j’avais l’habitude d’avoir avec un diaporama.

Cet article, c’est le guide que j’aurais aimé qu’on me donne avant que tout ça n’existe. Je pars du principe que tu es chef de produit ou responsable marketing, que tu n’as jamais déployé d’application, que tu as une vraie idée de produit que tu veux concrétiser, et qu’on t’a dit que tu devrais apprendre à « te mettre dans la peau d’un développeur ». À la fin de cet article, tu auras la feuille de route, les outils, ainsi que les compétences spécifiques et les MCP qui comptent le plus.

(Petite note sur la terminologie. On va appeler ça le « développement augmenté par l’IA » à partir de maintenant. C’est la même chose, mais ça sonne plus sophistiqué et c’est plus difficile à balayer d’un revers de main lors d’une réunion de direction.)

Une remarque sur les enjeux avant de commencer. Ce que tu vas créer ici, c’est un outil de conversation, pas du code de production. La distinction est importante. On y reviendra.

Une autre hypothèse que je pose : tu n’as pas de limite stricte de jetons pour ton utilisation de l’IA au travail. Si c’est le cas, ça change un peu la donne. Construis les bases par étapes plutôt que en un seul après-midi. Mets en place ton modèle de produit, ton fichier de principes et ton tableau de bord en plusieurs sessions. Une fois ces bases en place, chaque nouveau POC ne te coûtera qu’une fraction des jetons, car l’IA se contente surtout de cloner et d’ajuster plutôt que de tout générer à partir de zéro.

Ce dont tu as réellement besoin

Trois choses.

1. Un outil de codage IA. L’option de loin la plus accessible est l’application Claude Desktop. Connecte-toi, clique sur l’onglet « Claude Code ». C’est tout. Le même processus fonctionne dans Codex d’OpenAI ou Antigravity de Google si ton équipe préfère l’un de ces outils.
2. Un compte Upsun. C’est là que ton POC sera hébergé pour que d’autres personnes puissent y accéder. Inscris-toi sur upsun.com.
3. Une idée claire de ce que le POC doit démontrer. C’est la partie que la plupart des gens sautent. On va en parler.

Tu n’as pas besoin de connaître JavaScript, Python, Docker ou quoi que ce soit d’autre. Tu dois savoir ce que ton idée est censée faire. L’IA s’occupe de la partie technique. Toi, tu t’occupes de l’évaluation du produit.

Attention si ton entreprise ne te laisse pas utiliser une application IA sur ton ordinateur. Si tu dois utiliser ta propre clé API, opencode est l’interface en ligne de commande open source que j’ai utilisée. La configuration est un peu plus compliquée, mais le résultat final est le même.

Étape 1 : Ouvre l’outil et choisis un dossier

Si tu n’as jamais utilisé d’outil de codage basé sur l’IA, commence par Claude Desktop. Télécharge-le, connecte-toi, puis clique sur l’onglet « Claude Code ».

Voici ce que personne ne te dit d’emblée : tu dois choisir un dossier. Claude Code (et tous les autres outils de codage agentique) fonctionne à l’intérieur d’un seul répertoire de projet sur ton ordinateur.

Tu n’as pas besoin d’un dossier séparé pour chaque POC, et je te le déconseille vivement. La méthode que j’utilise, c’est un seul dossier pour tout. Ton modèle de produit s’y trouve. Chaque POC s’y trouve. Ton tableau de bord s’y trouve. Quand tu veux lancer ton cinquième POC, tu ouvres Claude Code dans le même dossier et tu dis « lançons un autre POC ». L’IA dispose déjà de tout le contexte : ton modèle, tes principes, tes POC précédents, ton tableau de bord.

Crée un nouveau dossier vide à un endroit logique (Bureau, Documents, là où se trouvent tes fichiers de travail). Appelle-le « pocs » et laisse-le se remplir. Indique-le à Claude Code quand il te le demande. À partir de maintenant, tous les fichiers créés par l’IA s’y trouveront.

Codex, Antigravity et opencode fonctionnent de la même manière. Choisis d’abord un dossier, puis lance la conversation.

Ne te prends pas la tête pour choisir l’outil. Le travail compte plus que l’outil.

Étape 2 : Configure d’abord tes compétences et tes MCP

Ça peut paraître contre-intuitif, mais la bonne chose à faire avant ta première commande, c’est d’installer tes compétences et tes MCP. Elles modifient le comportement de l’IA dès le tout premier message, et l’une d’entre elles (grill-me) est spécialement conçue pour que ta première commande soit plus claire.

Les compétences sont des instructions réutilisables que l’IA suit automatiquement. Les serveurs MCP sont des connecteurs vers d’autres outils (Notion, Linear, Figma, Slack, GitHub, etc.). Les plugins regroupent les deux.

La liste des éléments à installer est impressionnante si tu te lances dans les achats. Ne te lance pas dans les achats.

La commande que j’utilise en fait ressemble à ça :

« J’utilise Claude Desktop sur Mac. Installe pour moi la compétence grill-me du dépôt de Matt Pocock, la compétence Upsun et Context7. Explique-moi les étapes de configuration nécessaires, ou fais-le directement si tu peux. »

C’est tout. L’IA sait comment fonctionne son propre écosystème. Laisse-la s’occuper de l’installation. Tu ne cherches pas à optimiser une liste de compétences élégante. Tu cherches à optimiser le prochain prototype.

Les trois que j’installe sur chaque projet POC :

• Le dépôt de compétences de Matt Pocock, en particulier la compétence « grill-me ». Elle oblige l’IA à t’interroger sur ton idée avant de générer quoi que ce soit. Ça me permet de repérer la moitié de mes mauvaises hypothèses avant qu’elles ne se transforment en mauvais code.
• La compétence « Upsun ». Elle apprend à Claude à écrire correctement les fichiers de configuration Upsun dès le premier coup. Ça t’évite un aller-retour de déploiement.
• Context7. Fournit à l’IA de la documentation à jour pour n’importe quelle bibliothèque que tu utilises. Sans ça, l’IA invente parfois des noms de fonctions. Avec ça, le code se compile vraiment.

En plus de ça, installe les MCP pour les outils où se trouve réellement ton contexte. Notion ou Confluence pour les spécifications. Linear ou Jira pour les tickets. Figma pour les designs. Slack pour les conversations avec les clients.

Étape 3 : Formule la demande comme un cahier des charges

C’est la partie où la plupart des non-ingénieurs se trompent dès leur premier essai. Ils tapent « crée-moi une appli qui fait X ». Le résultat, c’est une coquille vide générique qui ne fait pas vraiment X.

Formule-la comme si tu donnais des instructions à un ingénieur senior en qui tu as confiance pour prendre des décisions, et appuie-toi sur les compétences que tu viens d’acquérir.

Un mauvais premier brief :

« Crée un outil où les utilisateurs peuvent importer un fichier CSV et voir un graphique. »

Un meilleur premier brief :

« Je suis responsable marketing produit dans une entreprise d’outils de développement. Je veux créer un POC cliquable qui illustre une idée de positionnement unique : “le document d’intégration de ton équipe, c’est le produit”. Utilise d’abord “grill-me” pour remettre en question mon cadrage et faire ressortir tout ce que je n’ai pas bien réfléchi. Une fois qu’on aura affiné le brief, voici ce que j’ai en tête : une appli web de deux pages. La première page accepte un fichier Markdown. La deuxième page affiche une version cliquable et navigable avec une barre latérale de titres et un widget « Évalue cette section » au bas de chaque section. Utilise React. Utilise la compétence Upsun pour que le projet soit prêt à être déployé sur Upsun dès le départ. Pas d’authentification, pas de base de données, un état en mémoire suffit. C’est un prototype jetable. Optimise-le pour que je puisse en faire une démo jeudi. »

La différence : tu as expliqué à l’IA à quoi sert le POC, quelle forme il doit prendre, quelles compétences utiliser, ce que tu veux optimiser et quels compromis tu es prêt à accepter. C’est le même brief que tu donnerais à un ingénieur senior. Le même brief fonctionne ici.

Astuce : fournis-lui ton vrai produit. Au minimum, glisse-lui trois ou quatre captures d’écran de ton application de production pour que le POC reprenne l’aspect et la convivialité de ton produit réel. Mieux encore, donne à l’IA l’URL de ton produit et demande-lui de lire ton site, d’identifier le stack technologique que tu utilises et de le recréer aussi fidèlement que possible. Plus ton POC ressemble à la version réelle, plus il sera facile pour les ingénieurs et les clients de se projeter dans l’idée plutôt que d’être déconcentrés par une interface utilisateur inconnue.

Astuce : commence en mode « plan ». La plupart des outils de type « agentic » en proposent un. Ça permet à l’IA de proposer un plan avant même de toucher à un seul fichier. Lis le plan, remets en question tout ce qui ne te convient pas, puis passe en mode automatique une fois que tu as validé ce qui va être développé. C’est un POC. Rapide et approximatif. Mais même « approximatif », ça vaut le coup de prendre cinq minutes pour établir un plan.

Étape 4 : itère à voix haute

Une fois que l’IA commence à développer, ton rôle est de lui parler comme à un collègue qui possède toutes les compétences techniques, mais qui ne connaît rien au contexte de ton produit.

Ce qui marche :

• « Le bouton de la page deux est trop petit. Fais en sorte qu’il ressemble à un CTA principal, pas à un lien de pied de page. »
• « Quand je télécharge un fichier sans titre, la barre latérale est vide et la page a l’air cassée. Affiche un état vide utile. »
• « C’est trop soigné. Fais en sorte que ça ressemble davantage à un prototype, exprès. Moins de finition, plus d’esquisse. »

Ce qui ne marche pas :

• Des consignes vagues. « Améliore ça. » L’IA va créer quelque chose de différent. Ça ne sera pas forcément mieux.
• Des modifications empilées dans un seul message. Donne-lui une chose à la fois. Tu avanceras plus vite, pas plus lentement.
• Le traiter comme un cahier des charges finalisé. Le POC révélera que tu ne savais pas vraiment ce que tu voulais. Tant mieux. C’est le but.

La plupart de mes POC passent par 15 à 25 allers-retours de ce genre de conversation pendant la première heure. C’est normal. La conversation, c’est le travail.

Astuce : dis à l’IA de noter ses principes. Quelque chose comme : « Crée un fichier PRINCIPLES.md dans ce projet. Note les choix de conception sur lesquels on vient de se mettre d’accord, et mets-le à jour chaque fois qu’on en change un. » Mes principes de base sont les suivants : l’API d’abord. Le mobile d’abord. Propose toujours un mode clair et un mode sombre. Donne-moi deux versions parmi lesquelles choisir, pas une seule. Clone toujours le modèle, ne le modifie jamais directement. Une fois que ces principes sont consignés par écrit, tu n’as plus besoin de réexpliquer tes préférences à chaque nouvelle conversation. La session suivante lit le fichier et reprend là où tu t’étais arrêté.

Étape 5 : Déploiement sur Upsun

Tu as maintenant une appli qui fonctionne sur ton ordinateur portable. Ton développeur ne peut pas la voir de là-bas. C’est là qu’Upsun entre en jeu.

Upsun est une plateforme d’applications cloud. En gros : tu lui indiques ton projet, elle se charge de l’héberger, te donne une URL et ne te dérange pas. Pour un POC, c’est exactement ce qu’il te faut. Tu ne veux pas avoir à te soucier des serveurs.

Le plus simple, c’est de laisser l’IA s’occuper de toute la configuration via le serveur MCP d’Upsun. Tu te connectes une seule fois. L’IA s’occupe du reste.

1. Inscris-toi ou connecte-toi sur upsun.com.
2. Clique sur ton nom dans le coin en haut à droite de la console Upsun pour ouvrir le menu de profil, puis clique sur « Jeton API ». Génère un jeton et copie-le.
3. Colle-le dans ton IA :

« Je veux déployer ce projet sur Upsun. J’ai un jeton API Upsun que je vais coller ci-dessous. Considère ce jeton comme une information confidentielle : ne me le répète pas, ne l’écris dans aucun fichier accessible, ne l’enregistre pas. Installe le serveur Upsun MCP avec les droits de lecture/écriture activés (par défaut, il est en lecture seule ; on a besoin des droits d’écriture pour que tu puisses créer le projet), puis crée un nouveau projet Upsun, pousse ce code, et donne-moi l’URL quand c’est fait. »

Un mot sur le jeton. Ce jeton API, c’est la clé de ton compte Upsun. Ne le colle pas sur Slack. Ne le commette pas dans un dépôt. Ne le partage pas avec un collègue qui a déjà ses propres identifiants. La phrase « considère ça comme un secret » dans l’invite ci-dessus est là exprès ; elle indique notamment à l’IA de ne pas enregistrer le jeton dans des journaux ou des fichiers où quelqu’un d’autre pourrait le lire plus tard.

L’IA installe le MCP, communique directement avec Upsun, crée le projet, pousse le code et te fournit une URL. En général, ça prend quelques minutes du début à la fin.

Astuce : utilise la CLI comme solution de secours. Si le MCP se bloque pour une raison quelconque, passe à la CLI d’Upsun : « Passe à la CLI d’Upsun. Installe-la, lance upsun login, crée un projet et envoie-le. » Même résultat, mais c’est un peu plus manuel.

Le guide officiel de la MCP est disponible sur developer.upsun.com.

Si une erreur survient à n’importe quelle étape, colle le message d’erreur dans l’IA. Neuf fois sur dix, elle connaît la solution.

Étape 6 : Rends-le accessible (le modèle du tableau de bord)

C’est l’astuce que j’aurais aimé qu’on me donne il y a six mois.

Ne déploie pas chaque POC comme une appli autonome que tu dois chercher dans les fils de discussion Slack. Crée un seul projet Upsun qui héberge tous tes POC, et mets un tableau de bord en entrée. Comme ton dossier de l’étape 1 contient déjà le modèle, tous les POC et le tableau de bord côte à côte, le tout se déploie ensemble sous la forme d’un seul projet Upsun. Le tableau de bord, c’est juste la porte d’entrée.

Chaque POC a droit à une vignette. Chaque vignette renvoie vers une page comportant trois onglets :

1. L’argument. Une explication écrite de ce qu’est le POC et de l’idée qu’il vient étayer.
2. La démo. Le POC lui-même, avec un bouton de visite guidée intégré qui automatise la découverte des fonctionnalités. Collecte le lien dans Slack, laisse le destinataire le regarder quand il le souhaite.
3. Les éléments de base. Une liste de ce qui existe déjà dans notre produit pour prendre en charge ce POC, ainsi que ce qu’il faudrait développer pour lancer les fonctionnalités pour de vrai.

C’est ce troisième onglet qui te permet de gagner la confiance de l’équipe d’ingénieurs. Il dit clairement : « Je ne prétends pas que c’est facile. Voilà ce qu’on devrait réellement développer. »

Astuce : crée un modèle de ton produit réel, une seule fois. Passe un après-midi à créer une structure minimaliste qui ressemble à ton produit réel, tant au niveau de l’apparence que de l’ergonomie. Les principaux composants de l’interface utilisateur sont en place, pas de véritable backend, des données factices. À partir de là, chaque nouveau POC commence par un « git clone » à partir de ce modèle. T’as déjà fait 30 % du boulot. Tes démos ressemblent au produit. Tes ingénieurs arrêtent de grimacer devant des modèles d’interface utilisateur inhabituels dans tes prototypes.

Astuce : développe ta propre compétence POC après quelques essais. Une fois que tu as livré un ou deux POC et que tu as cerné ton processus personnel, demande à l’IA de transformer ce processus en une compétence personnalisée. Indique-lui tes conventions (structure de dossiers, format du README, modèle d’onglet « primitives », style de configuration Upsun) et laisse-la créer la compétence pour toi. Après ça, chaque POC démarre automatiquement avec la bonne structure de base.

Astuce : le deuxième POC est bien plus rapide que le premier. Une fois que ton dossier contient un modèle, un fichier de principes, un tableau de bord et au moins un POC, ta demande pour le prochain POC se résume à une seule phrase : « Lançons un autre POC. Voici l’idée : [ton idée]. Clone le modèle, ajoute une vignette au tableau de bord, respecte les principes. » L’IA s’occupe du reste. La plupart de mes POC après le premier sont prêts en moins d’une heure, car toute la structure est déjà en place.

Étape 7 : Partage-le comme un prototype

C’est la partie culturelle. La façon dont tu partages le POC détermine s’il reste un simple POC ou s’il devient accidentellement le point de départ de la production.

Je ne suis pas fan de la formule « Alerte POC ! ». Personne ne parle vraiment comme ça. Ce que j’envoie sur Slack ressemble plutôt à ça :

« Bon, écoute-moi bien… Et si [l’idée défendue par ce POC] ? Voici une ébauche : [lien]. Clique un peu partout. Dis-moi ce qui te semble clair, ce qui ne l’est pas, et ce que tu supprimerais. C’est un POC, pas un point de départ. Je jetterai le code de toute façon. »

La formulation décontractée « écoute-moi bien » est importante. Ça invite à la discussion plutôt que d’exiger un examen. La phrase « POC, pas un point de départ » établit exprès la distinction entre production et prototype, pour que personne ne confonde l’appli fonctionnelle avec une version préliminaire du système de production.

Ne néglige pas la formulation.

Le kit de démarrage recommandé (tout en un)

Une version à copier-coller de ce qu’il faut installer.

Outil d’IA :

• Application Claude Desktop (la plus accessible), onglet Claude Code
• Alternatives : Codex, Antigravity ou opencode si ton entreprise exige des clés API

Compétences :

• Le dépôt de skills de Matt Pocock, en particulier grill-me
• La compétence « Upsun »
• Context7
• Ta propre compétence POC personnalisée (après quelques POC)

MCP (à installer là où ton équipe travaille vraiment) :

• Notion ou Confluence
• Linear, Jira ou Asana
• Figma
• Slack
• GitHub (facultatif)

Hygiène du projet :

• Un fichier PRINCIPLES.md géré par l'IA
• Un modèle fonctionnel de ton produit réel à cloner pour créer de nouveaux POC
• Un projet Upsun qui héberge tous tes POC, avec un tableau de bord

Tu peux être opérationnel en une heure. Encore plus vite si tu laisses l'IA s'occuper de l'installation.

Le compromis que je te dois

Les POC créés de cette manière présentent un véritable risque d’échec. Ils ont l’air terminés. Une application fonctionnelle avec de vrais boutons donne l’illusion d’être aboutie. Une fois la démo présentée, la question qui vient naturellement à l’esprit est « OK, on la met en production », et c’est là que les équipes se retrouvent en difficulté. Le code que l’IA a écrit en un après-midi n’est pas le code que quiconque devrait présenter devant des clients. Gartner a averti que « les approches de type “prompt-to-app” adoptées par les développeurs amateurs augmenteront les défauts logiciels de 2 500 % » d’ici 2028. Ils ont raison sur ce qui se passe quand personne ne fixe de limites.

Trace la limite. Puis franchis-la exprès, sous la houlette de l’ingénieur. Le POC, c’était la discussion. Le produit, c’est ce que tu vas construire ensuite, avec les bonnes personnes, la bonne rigueur et la bonne architecture.

Retour au tableau de bord

Le tableau de bord, ce n’était pas prévu.

Mon premier POC a été mis en place comme un projet autonome. Le deuxième aussi. Au troisième ou quatrième, c’était le bazar : des liens éparpillés dans les fils de discussion Slack, la moitié d’entre eux obsolètes, personne ne parvenait à retrouver la démo de la veille quand on voulait la montrer à un collègue.

J’ai donc demandé à Claude de créer le tableau de bord. Même processus que pour tous les autres POC. Deux heures plus tard, j’avais une page en mosaïque qui les regroupait tous au même endroit, avec le format à trois onglets que j’ai décrit plus haut. Maintenant, j’envoie une seule URL et je laisse le destinataire naviguer.

C’est ce que personne ne te dit. L’élément le plus précieux dans ce processus, ce n’est pas un POC en particulier. C’est le système que tu construis autour d’eux, qui rend les POC accessibles à tout le monde.

Crée ce prototype, même s’il n’est pas très beau. Déploie-le sur Upsun. Rends-le accessible. Puis fais en sorte que le suivant soit plus facile à réaliser que le précédent.

Le prototype, ce n’est pas le produit. C’est l’argument le plus rapide que tu puisses avancer pour montrer ce que le produit pourrait être. Le tableau de bord, au bout de huit mois, c’est la preuve que tout ça marche.

Maintenant, lance-en un.