Créer un produit numérique solo en 30 jours : retour brut

En bref — Créer un produit numérique seul en 30 jours est faisable, mais pas pour les raisons qu’on croit : l’IA ne remplace pas la réflexion stratégique, elle accélère l’exécution une fois que tu sais exactement quoi construire. Le vrai goulot d’étranglement n’est pas le code — c’est la décision.

Trente jours. Un seul dev. Zéro associé, zéro budget marketing, zéro réunion. Ce n’est pas un défi Twitter. C’est la réalité d’un studio indie solo — et c’est plus compliqué et plus instructif que n’importe quel thread de 280 caractères ne peut le résumer.

Ce retour d’expérience est chronologique, chiffré là où c’est possible, et honnête sur les moments où ça a failli dérailler. Si tu cherches de l’inspiration lisse, passe ton chemin. Si tu veux comprendre comment un produit numérique sort vraiment de terre en solo à l’ère de l’IA, lis la suite.

Semaine 1 : choisir l’idée et valider sans toucher au code

La première semaine, tu ne codes pas. Si tu codes en semaine 1, tu as déjà perdu.

La règle que j’applique : aucune ligne de code avant d’avoir une preuve, même minimale, que quelqu’un a le problème et qu’il cherche une solution. Pas un “c’est intéressant”, une vraie friction documentée.

Comment j’identifie l’idée

Je pars toujours d’une douleur que j’ai moi-même ressentie ou observée directement dans mon travail de dev freelance. Les idées venues de nulle part ont un taux d’abandon proche de 100 % — au moins sur les sprints courts. Quand le problème est réel pour toi, tu traverses les blocages de semaine 3 parce que tu veux la solution autant que tes futurs utilisateurs.

En pratique : je liste les tâches qui m’ont coûté du temps ou de l’énergie dans les 90 derniers jours. Pas des idées abstraites — des moments précis où j’ai pensé “il devrait exister un outil pour ça”.

La validation en 5 jours avec l’IA

L’IA entre en jeu ici, mais pas comme développeur. Elle joue le rôle d’un sparring partner critique.

Jour 1-2 : définir le problème avec précision. Je décris le problème à un modèle de langage et je lui demande de me poser des questions jusqu’à ce que la définition soit non ambiguë. Cet exercice prend 1 à 2 heures et révèle systématiquement des angles morts dans ma formulation initiale.

Jour 3 : cartographier les alternatives. Je demande à l’IA de lister tout ce qui existe déjà pour résoudre ce problème — outils, workarounds manuels, concurrents indirects. Si rien n’existe, ce n’est pas forcément bon signe : ça peut vouloir dire que le marché est trop petit ou que le problème n’est pas assez douloureux.

Jour 4 : construire une landing page en 4 heures. Pas de code custom. Un outil no-code ou un template, une proposition de valeur en une phrase, un formulaire d’inscription ou une liste d’attente. L’objectif : avoir une URL à partager.

Jour 5 : distribution manuelle. Je partage la landing dans 2 ou 3 communautés où le problème est discuté. Pas de spam — une réponse à un thread existant, un post qui apporte de la valeur avant de mentionner l’outil. Je mesure les clics, les inscriptions, les réponses directes.

Le seuil que je me fixe : si personne ne clique ou ne s’inscrit en 48 heures avec une distribution honnête, le problème n’est pas assez douloureux. Je pivote ou j’abandonne — et c’est une victoire, pas un échec. J’ai évité 3 semaines de développement sur quelque chose que personne ne voulait.

Semaines 2-3 : construire le MVP avec l’IA comme co-développeur

La validation passée, le sprint de développement commence. Deux semaines, pas trois. Si le MVP prend plus de 14 jours de code, c’est que le périmètre est trop large.

La règle des 3 fonctionnalités

Un MVP solo en 30 jours a exactement 3 fonctionnalités. Pas 5, pas 7. Trois. Celle sans laquelle le produit n’existe pas, celle qui rend l’expérience acceptable, et celle qui donne envie de revenir.

Tout le reste va dans un fichier backlog.md que je n’ouvre pas pendant le sprint. Cette discipline est la plus difficile à tenir — et la plus importante.

Comment l’IA accélère concrètement le développement

Je vais être précis, parce que “l’IA m’aide à coder” ne veut rien dire sans exemples.

Ce que l’IA fait bien dans un sprint solo :

Générer le boilerplate — authentification, gestion des rôles, emails transactionnels, connexion à une API tierce. Ce sont des tâches qui prenaient une journée entière et qui tombent à 2-3 heures avec un bon prompt et une vérification sérieuse du code produit.
Débloquer les impasses techniques — quand je suis bloqué sur un bug depuis plus de 30 minutes, je décris le contexte à l’IA. Elle propose 3 à 5 pistes. Une sur cinq est directement utilisable, les autres orientent ma réflexion. C’est plus rapide que Stack Overflow dans 70 % des cas.
Écrire les tests unitaires — je décris le comportement attendu, l’IA génère les tests. Je les relis et les corrige. Ça prend 20 minutes au lieu de 90.
Rédiger la documentation interne — README, commentaires de fonctions complexes, documentation d’API. Déléguer ça à l’IA me fait gagner 1 à 2 heures par semaine sans sacrifier la qualité.

Ce que l’IA ne fait pas bien :

Les décisions d’architecture. Quand je lui demande “comment structurer ma base de données pour ce cas d’usage”, elle me donne une réponse générique correcte mais pas adaptée à mes contraintes réelles (budget, volume attendu, stack existante). C’est moi qui décide.
La cohérence sur plusieurs sessions. L’IA ne se souvient pas du contexte d’hier. Je maintiens un fichier context.md que je colle en début de session pour éviter de tout réexpliquer.
La détection des failles de sécurité subtiles. Je relis tout le code lié à l’authentification et aux paiements moi-même, ligne par ligne.

Le rythme réel des semaines 2-3

Pas de journées de 14 heures. Des blocs de 4 à 6 heures de développement concentré, matin de préférence. Le soir : revue du code produit dans la journée, mise à jour du backlog.md, note des blocages pour le lendemain.

En semaine 3, la fatigue décisionnelle commence à se faire sentir. C’est là que le fichier de contexte et la règle des 3 fonctionnalités jouent leur rôle : ils éliminent les décisions à prendre et maintiennent le cap. L’IA porte la charge cognitive des tâches répétitives — moi je garde mon attention pour les décisions qui comptent.

À la fin de la semaine 3 : un produit qui fonctionne, déployé sur un vrai domaine, accessible aux personnes inscrites en semaine 1. Pas beau, pas complet, mais fonctionnel.

Semaine 4 : lancer, distribuer, mesurer — les vrais résultats

La semaine 4 n’est pas une semaine de développement. C’est une semaine de distribution. Si tu continues à coder en semaine 4, tu repousses le moment de vérité.

Ce que “lancer” veut dire concrètement en solo

Un lancement solo n’est pas un lancement Product Hunt avec 500 upvotes le jour J. C’est une mise à disposition progressive, canal par canal, avec mesure à chaque étape.

Jour 22-23 : activation des inscrits de semaine 1. Les personnes qui ont laissé leur email reçoivent un accès. Pas un email marketing — un message personnel (ou quasi-personnel avec personnalisation légère) qui explique ce qu’elles vont trouver et demande un retour direct. Le taux de réponse sur ce type de message dépasse 30 % quand la liste est petite et qualifiée.

Jour 24-25 : un post détaillé sur un canal. Pas un thread Twitter/X générique. Un post qui raconte le problème, la solution, et les premiers retours — avec des chiffres réels. Les communautés de makers et d’indie hackers répondent bien à ce format, à condition qu’il soit honnête et pas promotionnel.

Jour 26-28 : mesure et itération rapide. Je regarde trois métriques seulement : le nombre d’utilisateurs actifs (qui ont fait l’action principale au moins une fois), le taux de rétention à J+3 (est-ce qu’ils reviennent ?), et les retours qualitatifs directs (qu’est-ce qui bloque ?).

Jour 29-30 : décision. Continue, pivote ou arrête. Cette décision se prend sur les données, pas sur l’émotion.

Les vrais résultats d’un sprint 30 jours

Je vais être honnête sur ce qu’on peut raisonnablement attendre :

Un produit fonctionnel, déployé, avec de vrais utilisateurs : oui, c’est atteignable.
Des revenus récurrents significatifs au bout de 30 jours : non, sauf exception. La distribution prend du temps. Les premiers revenus arrivent généralement entre le jour 30 et le jour 90, si la validation initiale était bonne.
Un produit parfait : jamais. Et c’est le but. Un produit imparfait utilisé vaut infiniment plus qu’un produit parfait qui n’existe pas encore.

Ce que le sprint de 30 jours produit réellement, c’est une boucle de feedback réelle. Tu sais si tu résous un vrai problème. Tu as des données pour décider quoi construire ensuite. C’est ça, la valeur — pas le chiffre d’affaires du mois 1.

Pour aller plus loin sur les chiffres qui entourent l’économie du solopreneur et ce que l’IA change concrètement dans l’équation, j’ai compilé des sources sérieuses dans notre dossier statistiques solopreneur & IA 2026.

Ce que je referais différemment — et la leçon centrale

Après plusieurs cycles de ce type de sprint, voici les erreurs que je refais moins souvent — et celles que je vois systématiquement chez d’autres makers.

Les erreurs récurrentes

Commencer à coder trop tôt. C’est l’erreur numéro un. Le code donne une impression de progression. La validation donne une information réelle. Ce ne sont pas la même chose.

Sous-estimer la distribution. Un produit sans distribution n’existe pas. En solo, tu n’as pas d’équipe marketing — donc soit tu construis une audience avant de lancer, soit tu t’appuies sur des communautés existantes. Il n’y a pas de troisième option. Si le sujet de la distribution t’intéresse, l’audit de ton site peut révéler des problèmes de visibilité que tu n’avais pas identifiés.

Vouloir valider plusieurs idées en parallèle. En 30 jours solo, une seule idée à la fois. La dispersion tue les sprints courts.

Ignorer la fatigue décisionnelle. Après 15 jours de développement intensif, la qualité des décisions baisse. Mettre des systèmes en place (règle des 3 fonctionnalités, fichier de contexte, backlog fermé) n’est pas une question d’organisation — c’est une question de survie cognitive.

La leçon centrale

Le coût de construire un produit numérique s’est effondré. L’IA a rendu ça réel, pas juste théorique. Un dev solo en 2026 produit ce qu’une petite équipe produisait en 2019, sur certaines dimensions.

Mais le coût de décider quoi construire et pour qui n’a pas baissé d’un centime. C’est là que se joue l’essentiel. L’IA peut générer du code, rédiger des emails, débloquer des bugs — elle ne peut pas décider si ton idée vaut la peine d’être construite. Ça, c’est ton boulot.

Le sprint 30 jours est un outil de décision déguisé en outil de développement. Son vrai rôle : te forcer à confronter ton idée à la réalité avant d’y investir des mois.

Si tu es bloqué sur un aspect technique pendant un sprint de ce type — un bug qui résiste, une intégration qui ne passe pas — Unstuck existe pour ça : déblocage technique express, sans engagement long terme.

Trente jours, c’est court. Assez court pour maintenir l’élan, assez long pour avoir une vraie boucle de feedback. C’est le format qui correspond le mieux à la réalité d’un studio solo : pas de runway infini, pas d’équipe pour absorber les erreurs, mais une capacité à shipper et à apprendre vite que les structures plus lourdes n’ont pas.

Ship · Earn · Keep.

Sébastien de Bollivier est dev freelance depuis 2008 et construit des produits en solo depuis La Réunion. Si tu cherches un dev pour accélérer un projet ou valider une architecture, son profil est sur sebastiendebollivier.com.

Questions fréquentes

Est-il vraiment possible de créer un produit numérique seul en 30 jours ?

Oui, à condition de définir un périmètre MVP très strict (3 fonctionnalités max) et de valider l'idée avant d'écrire la moindre ligne de code. L'IA réduit le temps de développement de 40 à 60 % sur les tâches répétitives, mais la décision de quoi construire reste entièrement humaine.

Quelle stack technique choisir pour aller vite seul ?

Privilégie une stack que tu maîtrises déjà à 80 %. Changer de langage ou de framework pendant un sprint 30 jours est le moyen le plus sûr de ne pas finir. L'IA peut combler les 20 % restants — elle ne peut pas rattraper un choix de stack inadapté.

Comment distribuer un produit solo sans audience préexistante ?

Commence par un canal unique : une communauté ciblée (Discord, forum, subreddit) où ton problème est déjà discuté. Viser plusieurs canaux en semaine 4 d'un sprint solo, c'est se disperser. Un canal bien travaillé bat cinq canaux survolés.

Une idée à shipper ? Un site, un SaaS, une automatisation IA — construits avec toi.

Parler de ton projet