About this case study
Il s’agit d’un modèle que vous pouvez appliquer vous-même, pas d’un résultat client rapporté ni d’une promesse de portée.
Comment fonctionne la rotation sur quatre semaines
Vous avez construit l’app en un week-end avec Lovable, Bolt, Cursor ou Replit, et construire en public reste la distribution la moins chère à votre portée. Elle s’essouffle pour une raison banale : les semaines où rien de spectaculaire ne sort, vous ne publiez rien, et le compte se tait pendant quinze jours. Un modèle règle cela, parce que c’est le thème qui décide quoi publier avant que l’inspiration n’ait son mot à dire.
La rotation dure quatre semaines. La semaine 1 porte sur le problème et sur les personnes concernées. La semaine 2 sur les avancées et les décisions qui les expliquent. La semaine 3 sur les preuves : chiffres, éléments concrets et leçons. La semaine 4 sur la demande : retours, testeurs et suite du programme. Puis vous repartez de la semaine 1, avec un mois de matière neuve pour le raconter.
Dans chaque semaine, cinq publications endossent l’un des cinq rôles : problème, avancée, preuve, demande et leçon. Le rôle donne la forme, le thème donne le sujet, le réseau donne la longueur. Threads et X prennent les textes, Instagram prend une publication visuelle par semaine. Copiez les listes ci-dessous et remplissez les crochets.
Semaines 1 et 2 : le problème, puis les avancées
La semaine 1 fait qu’un inconnu reconnaît sa propre situation, et n’exige aucune nouvelle fonctionnalité. La semaine 2 montre du mouvement, et ne marche que si vous publiez la décision plutôt que le diff.
- Semaine 1 · Lundi · Problème · Threads et X — « La plupart des [audience] continuent à [méthode manuelle]. Cela leur coûte [temps ou argent] chaque semaine. C’est contre cela que je construis. »
- Semaine 1 · Mardi · Avancée · Threads et X — La plus petite partie fonctionnelle qui touche le problème, avec une capture : « Voici la partie qui remplace [étape]. Elle m’a pris [n] jours. »
- Semaine 1 · Mercredi · Preuve · Instagram — Une carte avant-après : « [Ancienne méthode] : quatorze étapes. [Nouvelle méthode] : deux. » Moins de douze mots sur l’image.
- Semaine 1 · Jeudi · Demande · Threads et X — « Si vous faites [la tâche] aujourd’hui, comment vous y prenez-vous vraiment ? Je lirai chaque réponse. » Puis répondez à chacune.
- Semaine 1 · Vendredi · Leçon · Threads et X — « Je pensais que [hypothèse]. Trois conversations plus tard, la vraie plainte est [réalité]. »
- Semaine 2 · Lundi · Avancée · Threads et X — « [Fonctionnalité] est en ligne. Elle existe parce que [utilisateur] ne pouvait pas [faire quelque chose]. » Une phrase, une capture.
- Semaine 2 · Mardi · Leçon · Threads et X — « J’ai choisi [option A] plutôt que [option B]. L’[option B] aurait pris trois semaines et servi moins de monde. »
- Semaine 2 · Mercredi · Preuve · Instagram — Un avant-après d’un écran refait, légendé par ce qui change pour la personne qui l’utilise.
- Semaine 2 · Jeudi · Avancée · Threads et X — La correction sans gloire : « J’ai passé [n] heures sur [problème ingrat] cette semaine. Personne ne le remarquera, et c’est le but. »
- Semaine 2 · Vendredi · Demande · Threads et X — « La suite, c’est [A] ou [B]. Laquelle utiliseriez-vous vraiment ? Une réponse tranche. »
Semaines 3 et 4 : les preuves, puis la demande
Un chiffre honnête vaut mieux que cinq affirmations floues et, sans chiffres, les preuves suffisent : citations, échanges de support, usage réel. La semaine 4 demande ensuite quelque chose de précis, car « allez voir » donne des résultats vagues.
- Semaine 3 · Lundi · Preuve · Threads et X — Un chiffre avec son dénominateur : « [n] personnes se sont inscrites ce mois-ci, [m] sont revenues la deuxième semaine. Voici ce que ces [m] ont en commun. »
- Semaine 3 · Mardi · Leçon · Threads et X — « J’attendais [hypothèse]. Les données disaient [réalité], donc j’ai supprimé [fonctionnalité]. »
- Semaine 3 · Mercredi · Preuve · Instagram — Une capture de vos statistiques avec les axes lisibles, plus une ligne de contexte. Ne rognez jamais un axe pour rendre une courbe plus raide.
- Semaine 3 · Jeudi · Preuve · Threads et X — Un utilisateur dans ses propres mots, avec son accord : « Quelqu’un l’a décrit comme [citation]. C’est devenu le titre de la landing page. »
- Semaine 3 · Vendredi · Leçon · Threads et X — « [Canal ou tactique] a donné [résultat] en [durée]. J’arrête, et voici ce que j’essaierais à la place. »
- Semaine 4 · Lundi · Demande · Threads et X — « Je cherche [n] [type de personne] pour tester [fonctionnalité] cette semaine. Répondez et je vous envoie une invitation aujourd’hui. »
- Semaine 4 · Mardi · Avancée · Threads et X — « Trois d’entre vous ont signalé [problème]. C’est corrigé depuis ce matin. »
- Semaine 4 · Mercredi · Preuve · Instagram — Le mois prochain en carte, en trois lignes : ce que vous construisez, ce que vous ne construirez pas, et quand.
- Semaine 4 · Jeudi · Demande · Threads et X — L’invitation, une fois par mois, sans excuses : « [App] fait [résultat] pour [audience]. Essai gratuit, lien ci-dessous. »
- Semaine 4 · Vendredi · Leçon · Threads et X — Le bilan du mois : une chose qui a marché, une qui n’a pas marché, un chiffre et une ligne sur le mois suivant.
20 idées de publications build in public qui ne s’épuisent jamais
Quand une case reste vide, prenez l’idée qui correspond au rôle. Chacune fonctionne, que vous ayez sorti quelque chose cette semaine ou non.
- Problème — Le bricolage que vos utilisateurs paient aujourd’hui, avec son coût réel.
- Problème — Une capture du tableur ou de la page Notion que votre app remplace.
- Problème — La question qu’on vous pose sans cesse en message privé, traitée en public.
- Problème — À qui l’app ne s’adresse pas, dit sans détour.
- Avancée — La fonctionnalité que vous avez livrée, en une phrase et une capture.
- Avancée — Ce que vous avez supprimé, et pourquoi l’app va mieux sans.
- Avancée — L’enregistrement d’un parcours qui demandait quatre clics et n’en demande plus qu’un.
- Avancée — Votre vraie semaine : heures de code, heures de support, heures de distribution.
- Preuve — Une métrique avec son dénominateur visible.
- Preuve — Un échange de support, anonymisé, qui a débouché sur un correctif.
- Preuve — Une citation d’utilisateur que vous n’avez pas écrite vous-même.
- Preuve — Ce que vous coûte l’app ce mois-ci, poste par poste.
- Demande — Deux options pour la suite, tranchées par une seule réponse.
- Demande — Un appel à testeurs avec un nombre et une date limite.
- Demande — Une demande d’avis sur un seul écran, image à l’appui.
- Demande — L’invitation mensuelle, avec un lien et sans excuses.
- Leçon — L’hypothèse qu’un utilisateur a démolie ce mois-ci.
- Leçon — Un changement de prix et ce qui s’est passé ensuite.
- Leçon — L’outil ou le canal que vous avez abandonné, et ce qui l’a remplacé.
- Leçon — Ce que vous feriez autrement si vous repartiez de zéro lundi.
Comment faire tourner ce modèle dans Amplispect
Le modèle tient le premier mois grâce à la volonté, et le troisième parce que quelque chose d’autre porte le calendrier. Dans Amplispect, cela commence par un espace de travail créé à partir de votre site : collez l’URL et il reprend votre offre, votre audience et votre ton de marque, pour que les brouillons ressemblent au produit plutôt qu’à un compte de fondateur générique.
Réglez la cadence sur cinq publications par semaine et laissez Amplispect générer la semaine à venir. Chaque publication générée arrive avec un rôle et une date, c’est-à-dire exactement la matière de ce modèle : votre travail consiste à y glisser les rôles qu’exige le thème en cours et à retoucher le texte avec les amorces sous les yeux. Relisez et programmez la semaine entière en une seule séance : l’éditeur prévisualise chaque publication par réseau, donc une légende trop longue pour X, ou un post Instagram sans image, est repérée avant d’entrer dans la file. Rien n’est publié sans votre validation.
Vient ensuite la partie quotidienne, environ quinze minutes : les réponses. Les commentaires des comptes connectés reviennent avec des réponses proposées que vous validez ou réécrivez, pour que la demande du jeudi devienne une conversation. En fin de mois, laissez la vue de performance choisir la rotation suivante. Si la semaine preuve a devancé toutes les autres, faites-en deux et réduisez le problème à une seule publication.
Ce qu’un mois comme celui-ci vous rapporte vraiment
Vingt publications, dont cinq demandes directes, quatre avec un chiffre réel, et une trace publique de chacune de vos décisions. Le résultat réaliste n’est pas un post viral. C’est que les gens qui vous suivent savent décrire ce que fait votre app sans l’ouvrir, et que vous ne vous asseyez plus un mardi en cherchant quoi dire. Les abonnés, les inscriptions et les installations restent des résultats à mesurer, pas des chiffres qu’un calendrier peut promettre.
Le garde-fou : n’embellissez pas les chiffres
Construire en public perd son seul avantage dès que les chiffres sont maquillés. Publiez le dénominateur avec la métrique, signalez comme tel tout ce qui est modélisé ou projeté, et ne rognez jamais l’axe d’un graphique pour flatter une courbe. La même honnêteté vaut pour la cadence : cinq publications par semaine que vous tenez valent mieux que quinze pendant quinze jours puis le silence. Si une semaine est vraiment vide, publiez une leçon, pas un jalon inventé.
Aller plus loin
Le reste du cluster et les deux pages produit sur lesquelles ce modèle s’appuie.
- Build in Public : une cadence de publication qui amène des utilisateurs, pas juste des abonnésLe raisonnement derrière la cadence que ce modèle programme, et comment en choisir une que vous tiendrez.
- Modèle de calendrier de contenu pour lancer une app : 3 semaines, jour par jourLa version semaine de lancement de ce calendrier, pour le mois où vous sortez enfin le produit.
- Typefully vs Amplispect pour le build in publicCe que vaut un outil d’écriture centré sur le texte face à un espace qui planifie, programme et gère les réponses.
- Comment écrire un changelog qui fait revenir les utilisateurs (et en attire de nouveaux)Transformez les posts d’avancée des semaines 2 et 4 en un changelog qui fait revenir les gens.
- Comment distribuer une app : le guide complet pour les fondateurs qui ont déjà construitLe tableau complet de la distribution, dont ce calendrier n’est qu’une pièce.
- Générateur de calendrier de contenu par IAGénérez la semaine à venir selon votre cadence, avec un rôle et une date sur chaque publication.
- Planificateur Instagram, Threads et XProgrammez la semaine sur les trois réseaux qu’utilise ce modèle, avec un aperçu par réseau.
Questions fréquentes
À quelle fréquence publier quand on construit en public ?
Cinq publications par semaine, c’est la cadence que suppose ce modèle : elle remplit un jour ouvré à la fois et laisse encore du temps pour répondre. Trois par semaine fonctionnent aussi si vous gardez la rotation intacte. Ce qui échoue, c’est quinze jours intenses suivis d’un mois de silence.
Que publier si rien n’est sorti cette semaine ?
Prenez un post problème, preuve ou leçon. Trois des cinq rôles n’exigent aucune ligne de code : le problème que résout votre app, un chiffre que vous avez déjà, ou une erreur que vous avez commise. C’est précisément pour cela que la rotation existe.
Quels réseaux marchent le mieux pour construire en public ?
Threads et X portent les publications texte, car tous deux récompensent les mises à jour courtes et précises et c’est là que se passent les réponses. Instagram prend la publication visuelle de la semaine. Amplispect publie sur ces trois réseaux ; tout ce que vous faites sur LinkedIn, Reddit ou TikTok reste du travail manuel.
Peut-on automatiser un calendrier de contenu build in public ?
La planification, oui. Amplispect génère la semaine selon votre cadence avec un rôle et une date sur chaque publication, et vous y glissez les rôles qu’appelle ce modèle. La publication attend toujours votre relecture, et les réponses restent les vôtres à écrire.