About this case study
Il s’agit d’un planning hebdomadaire modélisé que vous pouvez copier et ajuster, pas d’un résultat client rapporté ni d’une promesse qu’un nombre d’heures donné produira des utilisateurs.
La règle du 50/50 n’existe pas
La question revient chaque semaine sur les forums d’indie hackers : combien de temps consacrer au marketing plutôt qu’au développement ? La réponse la plus répandue est 50/50, et elle est fausse comme tout ratio fixe est faux. Une répartition figée suppose que le travail de distribution garde la même taille toute l’année, alors qu’il change de forme au moins trois fois dans les premiers mois d’une app.
La version 2026 de la question est de toute façon différente, parce que la moitié « développement » s’est effondrée. On passe d’une idée à une app déployée et fonctionnelle avec Lovable, Bolt, Cursor, v0 ou Replit en un week-end. Le goulot d’étranglement a bougé. Passer la moitié de sa semaine à coder alors que l’app fait déjà ce qu’elle promet, ce n’est pas de l’équilibre, c’est une cachette confortable.
Voici donc la réponse assumée. Pré-lancement : environ 80 pour cent de développement et 20 pour cent de distribution, soit à peu près 6 heures par semaine. Semaine de lancement : 30 pour cent de développement et 70 pour cent de distribution, soit environ 20 heures. Plateau post-lancement : 60 et 40 pour cent, soit environ 12 heures. Les pourcentages exacts comptent bien moins que le fait qu’ils bougent et que vous sachiez à quelle étape vous êtes.
Les trois semaines types ci-dessous supposent environ 30 heures de travail concentré. Si votre vraie semaine fait 12 heures à côté d’un emploi, réduisez chaque ligne dans la même proportion et gardez l’ordre. Ce qu’il ne faut pas faire, c’est calculer la moyenne des trois étapes, obtenir un chiffre confortable et appeler cela une stratégie.
Pré-lancement : 6 heures de distribution
Vous ne vendez pas encore. Vous rassemblez une audience à peu près de la bonne forme et vous apprenez les mots qu’elle emploie, pour que la semaine de lancement ait où atterrir.
- 2 heures, le lundi, en une seule séance : générer la semaine de publications depuis votre espace de travail, tout relire, réécrire ce qui sonne comme une brochure, supprimer ce qui n’est pas encore vrai et programmer le reste sur Instagram, Threads et X.
- 1 heure : écrire un texte plus long sur le problème, pas sur le produit, et le publier là où votre audience lit déjà.
- 1 heure : dix réponses sincères à d’autres personnes de votre niche. Sans lien, sans argumentaire, sans donner à quiconque l’impression d’être démarché.
- 1 heure : parler à deux personnes qui ont le problème. Un message privé, un appel ou un commentaire sous une plainte visant un concurrent comptent tous.
- 30 minutes : mettre à jour la landing page pour qu’elle décrive ce que vous avez réellement construit cette semaine.
- 30 minutes au total, cinq à dix minutes par jour : répondre aux commentaires sur vos propres publications.
- Il reste 24 heures pour développer, soit plus que ce que la plupart des fondateurs croient avoir.
Semaine de lancement : 20 heures de distribution
C’est la seule semaine où le développement perd volontairement. Gelez le code le vendredi précédent et n’y touchez que pour les bugs qui bloquent le lancement.
- 4 heures le week-end précédent : générer et éditer toute la semaine de lancement en une seule séance, chaque jour et les trois réseaux, en gardant les publications du jour J pour la fin.
- 2 heures : préparer ce qui n’est pas une publication. La vidéo de démo, trois captures d’écran et le paragraphe unique que vous collerez dans chaque formulaire d’annuaire.
- 3 heures le jour du lancement, réponses uniquement : chaque commentaire, citation et message privé traité dans l’heure, parce que c’est l’heure où l’algorithme et les gens regardent en même temps.
- 2 heures par jour le reste de la semaine, en deux blocs : réponses, relances et les personnes qui ont dit « intéressant, recontacte-moi plus tard ».
- 2 heures : les canaux manuels qu’aucun planificateur ne publie à votre place. Un post Reddit dans une communauté que vous fréquentez déjà, un post LinkedIn, un Show HN et un e-mail à tous ceux qui ont demandé des nouvelles.
- 1 heure le vendredi : noter en phrases simples ce qui a suscité des réponses et ce qui n’en a pas suscité, pour que la semaine suivante ne soit pas une devinette.
- 10 heures pour développer, ce qui veut dire en pratique des corrections, des textes d’onboarding et la chose que trois personnes ont demandée.
Plateau post-lancement : 12 heures de distribution
Le pic est retombé, la courbe est plate, et c’est l’étape où la plupart des fondateurs solos cessent discrètement de publier. Le planning existe pour rendre l’arrêt plus difficile que la poursuite.
- 2 heures, le lundi, en une seule séance : relire, éditer et programmer la semaine générée. C’est la seule séance où vous ouvrez le calendrier.
- 3 heures : une pièce substantielle par semaine, un changelog, une analyse ou un guide court, écrite pour pouvoir être découpée ensuite en plusieurs publications.
- 2 heures : la distribution que le planificateur ne fait pas. Une communauté, un échange de newsletters, une proposition à un podcast, un e-mail de partenariat.
- 2 heures : parler à cinq personnes qui se sont inscrites et ne sont jamais revenues. Leur demander ce qu’elles attendaient.
- 2 heures le vendredi : lire la vue de performance, noter quel rôle de publication a suscité des réponses et laisser la semaine suivante en tenir compte.
- 1 heure au total, dix à quinze minutes par jour : réponses et commentaires, rien d’autre.
- 18 heures pour développer, et construisez maintenant ce que ces cinq conversations vous ont dit de construire.
Pourquoi une séance de relecture vaut mieux que publier chaque jour
Le débat sur le 50/50 ne se règle jamais parce qu’on compare des heures sans comparer des formes. Quatre heures de développement, c’est un bloc. Quatre heures de distribution faites à la main, un peu chaque jour, ce sont quinze changements de contexte, et chacun vous coûte l’état mental que vous aviez sur le code. Les heures se valent sur une feuille de temps et ne se valent pas dans votre tête.
Alors condensez-les. Amplispect construit un espace de travail à partir de votre site, en reprenant votre offre, votre audience et votre voix de marque, puis génère la semaine de publications à la cadence que vous fixez, chacune avec un rôle et une date. Vous ouvrez cette semaine une fois, vous lisez tout, vous réécrivez ce qui est plat, vous supprimez ce qui n’est pas encore vrai et vous programmez ce qui survit. Les aperçus et les validations par réseau font que la légende qui casse sur X est repérée avant la mise en file, pas après.
C’est la ligne des deux heures du lundi dans chacune des trois semaines ci-dessus. Tout ce qui reste dans la colonne distribution est soit du travail qu’un outil ne peut vraiment pas faire à votre place, les messages privés, le post de communauté et les appels utilisateurs, soit les dix minutes quotidiennes passées à répondre à ceux qui ont répondu. Les commentaires des réseaux pris en charge se synchronisent dans le même espace de travail et peuvent être traités depuis des brouillons relus, ce qui garde le bloc quotidien en bloc plutôt qu’en tournée de trois applications.
Rien n’est publié sans que vous l’ayez lu. C’est tout l’échange : le planning protège vos heures de développement en rendant les heures de distribution prévisibles et bornées, pas en retirant votre nom des publications.
Ce que le planning vous apporte vraiment
Au bout d’un mois, vous avez une habitude de distribution qui survit à une mauvaise semaine : une séance de relecture défendable dans un agenda, dix minutes quotidiennes assez peu coûteuses pour être tenues, et une trace écrite des publications qui ont suscité des réponses. C’est une pratique qui se cumule et une vraie réponse à la question du temps. Ce n’est pas un chiffre de trafic, et aucun planning ne peut vous en promettre un.
Un calendrier ne crée pas la demande
Publier régulièrement ne crée pas de demande pour une app dont personne n’a besoin. Si huit semaines régulières ne produisent ni réponses, ni inscriptions, ni questions, le planning fonctionne correctement et vous dit quelque chose d’utile : le problème vient de l’offre, de l’audience ou de l’app. Changez l’un des trois avant d’ajouter des heures de publication.
Aller plus loin
Le reste de la série, si vous voulez les éléments que ce planning suppose déjà en place :
- Marketing d’app pour développeurs qui détestent le marketingQuoi faire des heures de distribution quand ce travail est précisément celui que vous redoutez.
- Build in Public : une cadence de publication qui amène des utilisateurs, pas juste des abonnésUne cadence pour la semaine générée, pour que les publications aient quelque chose d’honnête à dire un mardi calme.
- Comment distribuer une app : le guide complet pour les fondateurs qui ont déjà construitLe tableau complet de la façon dont une app trouve des utilisateurs une fois construite et déployée.
- Comment faire croître votre app avec une boucle hebdomadaireLe même rythme hebdomadaire quand vous êtes plus d’une personne à faire le travail.
- Pourquoi personne n’utilise votre app (et le fossé de distribution derrière)Ce qu’il faut vérifier en premier quand la semaine de plateau ne devient jamais de la croissance.
- Le planificateurRelire, valider et programmer une semaine pour Instagram, Threads et X en une seule séance.
- Créer un espace de travailCréer un espace de travail à partir de votre site et voir la première semaine générée.
Questions fréquentes
Combien de temps un indie hacker doit-il consacrer au marketing ?
Cela dépend de l’étape, pas d’un ratio fixe. Environ 20 pour cent de la semaine avant le lancement, jusqu’à 70 pour cent pendant la semaine de lancement et autour de 40 pour cent une fois le pic retombé. Sur une semaine de 30 heures, cela fait à peu près 6, 20 et 12 heures.
La règle du 50/50 entre développement et marketing tient-elle ?
C’est un bon slogan et un mauvais planning. Une répartition fixe ignore que la semaine de lancement demande beaucoup plus de distribution que le mois qui la précède, et qu’un plateau en demande plus qu’un pré-lancement. Faites bouger le ratio avec l’étape.
Peut-on faire le marketing d’une app en quelques heures par semaine en solo ?
Oui, à condition de grouper le travail. Générer et relire une semaine de publications en une séance, puis consacrer dix minutes par jour aux réponses, tient en quelques heures. Ce qui n’y tient pas, c’est inventer chaque publication le jour où vous la publiez.
Et si je publie régulièrement sans obtenir d’utilisateurs ?
Alors le planning a fait son travail en écartant la régularité comme explication. Après environ huit semaines sans réponses, sans inscriptions et sans questions, regardez l’offre, la définition de l’audience et l’app elle-même avant d’ajouter des heures de publication.