De l'idée au revenu : le plus petit produit viable que vous pouvez créer avec l'IA

L’ancienne méthode ne marche plus

Il y a cinq ans, la recette des startups était : choisir une idée, passer trois mois à construire le MVP, lancer dans le vide, itérer.

C’était l’époque où « MVP » voulait dire « toutes les fonctionnalités de base, super peaufinées, prêtes pour une liste d’attente ».

Avec les créateurs d’applis avec IA comme Proyecta, le calendrier est différent. Vous pouvez avoir quelque chose de réel — pas une page d’atterrissage, pas une maquette, mais un vrai produit qui fonctionne — d’ici demain midi. Mais presque personne ne sait comment réfléchir à ce que « le plus petit » veut vraiment dire quand on crée avec l’IA.

Voici ce que je constate : la plupart des gens lancent beaucoup trop de choses. Ils ajoutent un tableau de bord, des comptes utilisateurs, des intégrations, des statistiques, peut-être une version appli mobile. Puis personne ne l’utilise, parce qu’ils optimisaient pour l’exhaustivité — cocher des cases — au lieu de résoudre un problème précis pour une personne précise, tout de suite.

Ce que « le plus petit » veut dire aujourd’hui

Le plus petit produit viable avec l’IA est si petit que c’en est presque drôle. C’est :

Un seul flux. Pas cinq fonctionnalités. Une seule chose que votre personne cible fait à répétition et qui lui prend aujourd’hui 10 minutes, et que votre appli ramène à 30 secondes.

Pas de comptes. Si vous pouvez le lancer sans connexion — faites-le. Une personne, une session, un résultat. Si ça plaît, vous pourrez ajouter les comptes plus tard. Mettre en place un parcours de connexion Stripe correctement prend 20 minutes. Les sessions ponctuelles en prennent cinq.

Pas de base de données. Du moins pas une que vous gérez. Mettez vos données dans un Google Sheet. Utilisez localStorage dans le navigateur. Servez-vous de Stripe ou d’Airtable comme backend. Vous cherchez à trouver des clients, pas à construire une infrastructure.

Une seule intégration. Choisissez l’unique outil que votre client utilise déjà et intégrez-le. « Fonctionne avec Slack » ou « lit depuis votre Google Drive » est bien plus utile que « possède son propre système de classement ».

Voici un exemple concret : Sarah a créé un outil pour les designers freelances qui passent un temps fou à expliquer leur style à de nouveaux clients. Son appli : vous téléversez trois de vos meilleures réalisations, vous décrivez votre démarche en langage clair, et l’appli génère une « charte de style » en PDF que le designer peut envoyer à ses clients. C’est tout. Pas de comptes, pas de connexion, pas de tableau de bord. À chaque utilisation, on repart de zéro. L’appli tourne dans Proyecta, elle utilise Stripe pour les paiements (qui génère un lien unique par PDF), et quand les gens réclament plus de fonctionnalités (comme « enregistrer plusieurs styles »), elle pourra l’ajouter — ou elle pourrait se rendre compte que son vrai produit n’est pas l’appli, mais la vente de ces chartes comme modèles.

Elle a gagné 600 $ la première semaine.

Les trois indicateurs qui comptent vraiment

Ne mesurez pas l’exhaustivité. Ne mesurez pas le temps passé sur le site. Mesurez ces trois-là :

1. Le temps jusqu’à la première valeur. De « j’ai trouvé ce lien » à « j’ai obtenu un résultat que je peux vraiment utiliser ». Pour l’outil de Sarah : 90 secondes. Si ça prend plus de cinq minutes, les gens abandonnent.

2. La disposition à payer. Ne lancez pas avec une offre gratuite et une offre Pro. Choisissez un seul prix. Voyez si les gens sont prêts à le payer. (25 $ pour les PDF de Sarah. Elle pourrait demander plus ; elle demande moins parce qu’elle veut juste valider.) Si la réponse est « pas question », vous avez choisi le mauvais problème.

3. Le taux de retour. Pour un outil ponctuel, vous n’avez pas besoin d’une rétention à 30 jours. Vous avez besoin de savoir : parmi les gens qui l’ont utilisé une fois, combien en parlent à un ami ? L’indicateur de rétention de Sarah, c’est « en a parlé à au moins un autre designer ». Pour l’instant, c’est 40 %.

Si les trois sont bons, vous tenez quelque chose. Vous pouvez alors ajouter les comptes, les tableaux de bord, l’historique, tout ça.

Comment lancer en un week-end

Vendredi matin : choisissez votre problème. Pas un marché. Pas une tendance. Une personne précise qui fait une chose précise et agaçante aujourd’hui.

Vendredi après-midi à samedi matin : utilisez Proyecta pour le construire. Vous décrivez ce que vous voulez (« prends un contrat PDF et surligne en rouge toutes les clauses de paiement »), Proyecta le génère, vous le testez, vous l’ajustez jusqu’à ce que ça marche. Quatre heures, peut-être six si vous êtes pointilleux. Vous avez maintenant une appli web qui fonctionne.

Samedi après-midi : testez-le sur deux personnes. Pas « eh, tu utiliserais ça en théorie ? » mais « voici le lien, sers-t’en pour de vrai, et dis-moi ce qui a cassé ou semblé bizarre ».

Dimanche matin : mettez en place le paiement si vous facturez. Stripe, Gumroad, un simple lien — vous ne construisez pas une plateforme de facturation. Juste un moyen d’encaisser.

Dimanche soir : lancez-le. Postez sur Show HN, sur un Discord ou un Slack pertinent, écrivez directement à cinq personnes. Ne vous tracassez pas avec la description. Commencez par le pourquoi : « J’ai fait ça parce que ça m’agaçait de… »

Lundi : observez ce qui se passe vraiment. De vraies personnes l’utilisent ou pas. Vous le saurez en 48 heures.

Ce qui se passe ensuite (la partie facile)

Si personne ne l’utilise : vous avez appris quelque chose vite et à moindre coût. Vous pivotez dès mardi.

Si quelques personnes l’utilisent : observez ce qu’elles en font vraiment. L’utilisent-elles exactement comme vous l’aviez conçu, ou font-elles quelque chose de légèrement différent ? Réclament-elles des fonctionnalités que vous n’aviez pas prévues, ou s’en servent-elles discrètement avant de repartir ?

Si les gens l’utilisent, demandent des choses, et que vous êtes sûr de vouloir travailler là-dessus : maintenant vous pouvez investir dans le sérieux. Des comptes, pour que les gens enregistrent leur travail. Un tableau de bord, pour qu’ils voient ce qu’ils ont créé. Une API, si c’est ce dont ils ont besoin. Mais vous construisez ces fonctionnalités parce que vous savez qu’il y a une demande, pas parce que vous pensez qu’elles devraient exister.

La plus grosse erreur est de lancer en partant du principe que votre idée est juste et que votre seul travail est d’en convaincre les gens. Le plus petit produit viable est le premier test de ce principe. Tout ce qui vient après n’est que de l’écoute.

Trois histoires vraies

Marcus (analyste de données) : passait une heure par semaine à reformater manuellement des requêtes SQL pour les analystes juniors. Il a créé un outil dans Proyecta qui le fait en un clic : collez la requête, obtenez la version formatée. Un seul champ, un seul bouton. Lancé un mardi. Dès le vendredi, il avait 300 utilisations de gens de son Discord. À la fin du mois : 1 200 utilisations, dont certaines de parfaits inconnus. Il a ajouté des comptes pour que les gens consultent leur historique, puis a construit une intégration avec son entrepôt de données. C’est aujourd’hui sa deuxième source de revenus.

Jade (illustratrice) : a créé un outil qui prend un mémo vocal et génère un croquis de personnage à partir de la description. 45 minutes pour le construire. 3 $ par croquis. 1 500 $ gagnés en deux semaines avant de le mettre en pause, parce qu’elle recevait tellement de commandes qu’elle ne suivait plus côté administratif.

Omar (fondateur) : voulait construire une « plateforme complète ». Deux mois de travail. Lancé avec des comptes, des paliers tarifaires, des intégrations à trois outils et une vidéo tutorielle. Trois mois plus tard : 12 utilisateurs, dont deux étaient ses amis. Il a compris qu’il avait optimisé pour le lancement et non pour l’apprentissage. Sa nouvelle version est bien plus petite — juste le flux principal — et il commence à avoir une vraie traction.

Ce que personne ne vous dit

Lancer petit fait peur, parce que ça donne une impression d’inachevé. Votre cerveau hurle « mais il faut gérer [tel cas particulier], et [telle fonctionnalité], on ne devrait pas [ajouter de la complexité] ? »

Non. Lancez quand même.

Votre travail n’est pas de construire le produit parfait. Votre travail est de tester le plus petit pari qui prouve que vous résolvez un vrai problème pour une vraie personne. Tout ce qui vient après n’est que de l’écoute et de l’itération basées sur le réel.

---

Que pourriez-vous créer ce week-end avec un créateur d’applis avec IA ? Quelque chose de minuscule. Quelque chose que vous utiliseriez vous-même. Essayez et voyez.