Image : Absolute Perfection Media — Openverse (by-sa)
Le build-in-public, mode d'emploi : construire son audience en shippant
Tu codes le soir. Tu ship le week-end. Tu as trois utilisateurs — dont ta mère et ton compte secondaire. Le produit avance, mais personne ne le sait. Tu pourrais acheter des ads, écrire une newsletter, tenter le SEO. Ou tu pourrais faire la chose la plus contre-intuitive du monde : montrer exactement ce que tu fais, en temps réel, à des inconnus sur internet.
C'est le build-in-public. Pas un concept marketing fumeux. Un canal de distribution à part entière, utilisé par des makers qui ont compris que l'attention se gagne avant le lancement, pas après.
Ce guide est pour toi si tu veux t'y mettre mais que tu bloques sur la même question que tout le monde : qu'est-ce que je suis censé raconter, exactement ?
Pourquoi construire en public est un canal de distribution
Le build-in-public n'est pas du personal branding déguisé. C'est un mécanisme d'acquisition organique qui repose sur un principe simple : les gens s'attachent aux histoires en cours, pas aux produits finis.
Quand tu partages ton processus de construction, tu crées trois effets simultanés.
L'effet de feuilleton. Chaque post est un épisode. Ton audience revient pour savoir si tu as résolu le bug de la veille, si tu as atteint les 100 utilisateurs, si le pivot a fonctionné. Tu ne vends rien — tu embarques des gens dans un récit dont la fin n'est pas écrite.
L'effet de preuve. Un maker qui montre son code, ses métriques, ses erreurs est infiniment plus crédible qu'une landing page avec des témoignages anonymes. La transparence est la forme la plus efficace de social proof parce qu'elle est impossible à simuler sur la durée.
L'effet de réseau. Les makers qui construisent en public attirent d'autres makers. Ils se retweetent, se commentent, se recommandent. Twitter (X), Indie Hackers, les communautés Slack — ces espaces fonctionnent comme des amplificateurs naturels pour ceux qui jouent le jeu de la transparence.
Le résultat concret : tu construis une audience avant d'avoir un produit terminé. Le jour du lancement, tu ne pars pas de zéro. Tu as des gens qui attendent, qui ont suivi chaque étape, qui se sentent investis dans ta réussite. Ce sont tes premiers clients, tes premiers ambassadeurs, tes premiers feedbacks.
Pieter Levels a construit 12 startups en 12 mois en racontant tout publiquement. Il n'avait pas de budget marketing. Il avait un fil Twitter. Nomad List, son produit phare, a été financé par une audience qu'il avait construite post après post, screenshot après screenshot.
Ce n'est pas une anomalie. C'est un canal reproductible.
Quoi partager (et quoi garder pour toi)
C'est là que la plupart des makers se paralysent. L'idée de "tout montrer" fait peur — et elle devrait, parce qu'elle est fausse. Le build-in-public ne veut pas dire zéro filtre. Il veut dire filtre intentionnel.
Ce qui fonctionne
Les décisions et leur raisonnement. "J'ai choisi Postgres plutôt que MongoDB parce que..." vaut mille fois plus qu'un screenshot de code. Les gens veulent comprendre comment tu penses, pas ce que tu tapes.
Les métriques d'avancement. Nombre d'utilisateurs, MRR, taux de conversion, trafic. Pas besoin que les chiffres soient impressionnants. Un post "Jour 30 : 14 utilisateurs, 0 € de revenu, voici ce que j'ai appris" génère plus d'engagement qu'une annonce de levée de fonds.
Les échecs et les pivots. "Cette feature que j'ai passé 3 semaines à coder ? Personne ne l'utilise. Voici pourquoi je la supprime." Ce type de contenu est de l'or. Il est rare, honnête, et il crée une connexion émotionnelle immédiate.
Les coulisses du process. Tes outils, ton organisation, ta stack technique, ta routine de travail. Les makers adorent le méta — savoir comment les autres makers travaillent.
Les petites victoires. Premier utilisateur payant. Premier email de feedback positif. Premier jour à 100 visiteurs. Ces micro-moments sont le carburant narratif du build-in-public.
Ce que tu gardes pour toi
Les données sensibles de tes utilisateurs. Ça paraît évident, mais dans l'enthousiasme de la transparence, certains partagent des screenshots avec des emails visibles ou des données personnelles. Non.
Les détails de ton avantage compétitif. Si tu as trouvé un canal d'acquisition inexploité, un algorithme propriétaire, ou un partenariat stratégique en négociation — garde-le. La transparence ne veut pas dire naïveté.
Les conflits avec des personnes identifiables. "Mon cofondateur est parti" peut se raconter. "Mon cofondateur est parti parce qu'il est incompétent" ne devrait pas. Le build-in-public n'est pas un tribunal.
Ce qui te met en danger légalement. Contrats en cours, discussions avec des investisseurs sous NDA, données financières réglementées. La frontière entre transparence et imprudence est juridique autant que morale.
La règle que j'utilise : partage le quoi et le pourquoi, protège le qui et le comment spécifique. "Notre conversion a doublé quand on a changé le pricing" → oui. "Voici le spreadsheet exact de notre modèle de pricing avec les marges par segment" → non.
La régularité bat l'intensité
Tu n'as pas besoin de threads viraux. Tu as besoin de présence constante.
Le build-in-public est un jeu de compound interest appliqué à l'attention. Un post par jour pendant 90 jours bat un thread épique suivi de trois semaines de silence. Toujours. Voici pourquoi.
Les algorithmes récompensent la constance. Sur Twitter/X, sur LinkedIn, sur n'importe quelle plateforme — poster régulièrement signale aux algorithmes que tu es un créateur actif. Ta portée organique augmente avec ta fréquence, pas avec la qualité isolée d'un post.
L'audience a besoin de rituels. Les meilleurs comptes build-in-public ont des formats récurrents. Le "weekly update" du lundi. Le "metrics Monday". Le "Friday ship". Ces rituels créent de l'attente et de l'habitude chez ton audience.
La pression de la régularité te force à avancer. C'est l'effet secondaire le plus sous-estimé. Quand tu sais que tu dois poster un update demain, tu trouves quelque chose à shipper aujourd'hui. Le build-in-public devient un mécanisme de responsabilité personnelle.
Un framework minimal pour démarrer
Pas besoin d'un calendrier éditorial complexe. Commence avec ça :
- Lundi : objectifs de la semaine (2-3 max)
- Mercredi : un apprentissage ou une décision prise en cours de route
- Vendredi : ce qui a été shippé, ce qui ne l'a pas été, pourquoi
Trois posts par semaine. Moins de 15 minutes par post. Aucune excuse pour ne pas le faire.
Si tu veux monter en intensité plus tard, ajoute des posts quotidiens courts — un screenshot, une métrique, une question à ton audience. Mais ne commence pas par là. Commence par un rythme que tu peux tenir pendant six mois sans t'épuiser.
Le piège classique : le maker qui poste 4 fois par jour pendant deux semaines, se lasse, disparaît, et conclut que "le build-in-public ne marche pas". Le build-in-public marche. L'intensité non soutenable, elle, ne marche jamais.
Les chiffres à nu : jusqu'où aller
La question revient en boucle dans les communautés de makers : faut-il partager son revenu ? Ses coûts ? Ses échecs financiers ?
La réponse courte : plus tu es spécifique, plus tu es crédible. Mais la spécificité a des paliers, et tu choisis le tien.
Palier 1 : les tendances
"Le MRR a augmenté de 30 % ce mois-ci." Tu donnes la direction sans le chiffre absolu. C'est suffisant pour créer de l'intérêt et montrer de la traction. C'est le palier le plus confortable pour commencer.
Palier 2 : les chiffres absolus
"MRR : 2 400 €. 47 clients payants. Churn : 8 %." C'est le sweet spot du build-in-public. Assez précis pour être crédible, assez contextuel pour être utile à d'autres makers. La majorité des comptes build-in-public qui fonctionnent opèrent à ce palier.
Palier 3 : la transparence totale
Dashboard public, open metrics, P&L partagé. C'est ce que font des projets comme Baremetrics (qui a littéralement construit un produit autour de ça) ou certains makers comme Jon Yongfook avec Bannerbear. Ce palier est puissant mais il a un coût : tes concurrents voient tout, tes clients savent exactement combien tu gagnes, et la pression de la performance publique peut devenir toxique.
Comment choisir ton palier
Pose-toi deux questions :
Est-ce que ces chiffres peuvent être utilisés contre moi ? Si tu négocies avec un client enterprise et qu'il voit que ton MRR est de 800 €, ça peut changer la dynamique. Si tu vends à des indie makers, ça renforce ta crédibilité.
Est-ce que je suis à l'aise avec ces chiffres dans six mois, même s'ils baissent ? Parce qu'ils baisseront peut-être. Et le build-in-public, c'est aussi montrer les mois difficiles. Si tu n'es pas prêt à poster "MRR : 1 200 € (en baisse de 40 %)", ne poste pas "MRR : 2 000 €" aujourd'hui.
Un principe souvent oublié : les chiffres modestes sont plus engageants que les gros chiffres. Un maker à 500 € de MRR qui raconte son chemin vers 1 000 € génère plus de connexion émotionnelle qu'un SaaS à 50K qui partage son dashboard. L'audience du build-in-public s'identifie aux débuts, pas aux sommets.
Les erreurs qui font fuir l'audience
Le build-in-public a ses propres pièges. Certains sont évidents, d'autres sont insidieux. Voici ceux qui tuent le plus de comptes.
Le humble brag permanent
"Tellement overwhelmed par le nombre de demandes de démo 😅" n'est pas du build-in-public. C'est du personal branding déguisé en vulnérabilité. L'audience le détecte en une seconde. Si tu veux partager une bonne nouvelle, partage-la directement : "43 demandes de démo cette semaine, voici comment je les gère." La fausse modestie est le moyen le plus rapide de perdre la confiance de ton audience.
Le build-in-public sans le build
Poster des réflexions sur l'entrepreneuriat, des citations motivationnelles, des avis sur les outils du moment — ce n'est pas construire en public. C'est du contenu générique avec un hashtag. Le "build" dans build-in-public est le mot le plus important. Si tu ne shippes rien, tu n'as rien à raconter. Et ton audience le voit.
L'obsession des métriques de vanité
Partager ton nombre de followers, tes impressions, tes likes — personne ne s'en soucie. Les métriques qui intéressent ton audience sont celles de ton produit, pas celles de ton compte Twitter. Nombre d'utilisateurs, revenu, rétention, bugs corrigés, features shippées. Le reste est du bruit.
Le ton plaintif
"Personne ne s'inscrit." "Je ne sais pas si je vais continuer." "C'est tellement dur." Partager les moments difficiles est essentiel — mais il y a une différence entre la vulnérabilité et la plainte. La vulnérabilité dit : "Ce mois a été dur, voici ce que j'en tire." La plainte dit : "Ce mois a été dur" et s'arrête là. La première crée de la connexion. La seconde crée du malaise.
Ignorer les réponses
Le build-in-public est un canal bidirectionnel. Si des gens prennent le temps de commenter, de poser des questions, de donner du feedback — et que tu ne réponds jamais — tu casses le contrat implicite de la transparence. Tu ne peux pas demander à une audience de s'investir dans ton histoire si tu ne t'investis pas dans la conversation.
Commence aujourd'hui, pas lundi
Le build-in-public n'a pas besoin d'un plan parfait. Il a besoin d'un premier post.
Ouvre Twitter, LinkedIn, ou la plateforme où traînent tes futurs utilisateurs. Écris ce sur quoi tu travailles en ce moment. Ce que tu essaies de résoudre. Où tu en es. Ce sera imparfait, probablement maladroit, et c'est exactement le point.
Les makers qui réussissent en build-in-public ne sont pas ceux qui ont la meilleure plume ou les meilleurs chiffres. Ce sont ceux qui ont posté le premier jour, puis le deuxième, puis le troisième. La régularité bat l'intensité. La transparence bat le polish. Et shipper en public bat construire dans l'ombre.
Ton audience ne t'attend pas. Elle ne sait pas encore que tu existes. C'est à toi de le lui montrer — un post à la fois.
Envie de passer du « je devrais » au « c'est en ligne » ? Commence par valider ton idée, puis distribue-la. graine de startup est édité par le studio de Sébastien Debollivier.