Pourquoi construire en public sur X
Construire en public transforme ton travail quotidien en matière à posts : tu n’inventes pas de sujets, tu racontes ce qui se passe vraiment.
Le premier bénéfice n’est pas l’audience, c’est la régularité. Un fondateur qui construit a toujours quelque chose à dire : une fonction livrée, un client qui part, un prix qui change, une erreur de cible. Ce sont des faits que personne d’autre ne peut écrire à ta place, et c’est exactement ce qui distingue un compte qu’on suit d’un compte qu’on oublie.
Le deuxième bénéfice tient à la façon dont X classe les posts. Le code publié par X prédit, pour chaque lecteur, la probabilité de plusieurs actions puis en fait une somme pondérée ; les réponses, les citations, le partage en message privé et la copie du lien pèsent bien plus que le like. Un post qui raconte une décision réelle, avec un chiffre et une question honnête, donne des raisons de répondre et d’envoyer le post à quelqu’un. Pour le détail des poids, lis le guide de l’algorithme de X.
Enfin, le build in public crée une identité claire : on sait ce que tu construis, pour qui, et où tu en es. C’est le cœur du personal branding sur X appliqué à un projet.
Ce que tu partages, ce que tu gardes
Partage les décisions et ce qu’elles t’ont appris ; garde pour toi ce qui expose tes clients, ta sécurité ou ta trésorerie.
Construire en public ne veut pas dire tout publier. La règle utile : un chiffre ou un détail n’a sa place que s’il aide le lecteur à comprendre une décision. Le reste est du bruit, ou un risque.
| Sujet | Partager | Garder pour toi |
|---|---|---|
| Revenus | MRR arrondi, évolution, ce qui l’a fait bouger | Détail par client, montants qui permettent d’identifier quelqu’un |
| Clients | Le problème qu’ils avaient, avec leur accord | Noms, captures avec des données, échanges privés |
| Produit | Fonctions livrées, choix techniques, ce que tu as retiré | Failles non corrigées, détails d’infrastructure exploitables |
| Échecs | Ce qui n’a pas marché et pourquoi | Règlements de comptes, reproches nominatifs |
| Argent | Prix, changements de prix et leur raison | Trésorerie exacte si elle te met en position de faiblesse |
Revenus
- Partager
- MRR arrondi, évolution, ce qui l’a fait bouger
- Garder pour toi
- Détail par client, montants qui permettent d’identifier quelqu’un
Clients
- Partager
- Le problème qu’ils avaient, avec leur accord
- Garder pour toi
- Noms, captures avec des données, échanges privés
Produit
- Partager
- Fonctions livrées, choix techniques, ce que tu as retiré
- Garder pour toi
- Failles non corrigées, détails d’infrastructure exploitables
Échecs
- Partager
- Ce qui n’a pas marché et pourquoi
- Garder pour toi
- Règlements de comptes, reproches nominatifs
Argent
- Partager
- Prix, changements de prix et leur raison
- Garder pour toi
- Trésorerie exacte si elle te met en position de faiblesse
Une capture d’écran de tableau de bord montre souvent plus que le chiffre visé : emails de clients, noms de projets, adresses. Recadre ou réécris le chiffre en texte.
Le rythme : petit et régulier plutôt que rare et spectaculaire
Un rythme tenable vaut mieux qu’un grand récit mensuel : un post de progrès par semaine, un bilan par mois, et les événements quand ils arrivent.
Le fil « Pour toi » ne garde un post éligible que pendant 48 heures, et il espace les posts d’un même auteur dans un même chargement : chaque post supplémentaire du même compte voit son score réduit. Publier dix posts le jour d’un lancement puis rien pendant trois semaines est donc doublement perdant. Mieux vaut étaler.
- Chaque semaine : un post sur ce que tu as livré ou appris, avec un détail précis.
- Chaque mois : un bilan court (chiffres arrondis, ce qui a marché, ce que tu changes).
- À l’événement : un palier franchi, une release, un échec, une décision de prix.
- Entre les deux : des réponses aux autres fondateurs de ta niche, qui comptent autant que tes posts (voir le guide sur les réponses et les mentions).
Pour savoir quand publier ces posts, pars des repères du guide du meilleur moment puis mesure sur tes propres posts.
Paliers de MRR : raconter un chiffre sans se vanter
Un palier de MRR intéresse par ce qui l’a rendu possible, pas par le chiffre seul : donne le chiffre, le temps, et la ou les causes.
Le post de palier est le format le plus attendu du build in public, et le plus souvent raté : un chiffre, un emoji de fusée, des remerciements. Ce qui se partage, c’est la cause. Qu’est-ce qui a changé entre le palier précédent et celui-ci ? Un canal, une fonction, un prix, une cible ?
[Produit] vient de passer [palier] de MRR. Il a fallu [durée] depuis [palier précédent]. Ce qui a vraiment fait la différence : 1. [cause 1, avec un détail précis] 2. [cause 2] 3. [ce que j’ai arrêté de faire] Ce que je change pour le prochain palier : [décision].
Remplace chaque crochet par tes vrais chiffres. Si tu n’as pas de cause claire, dis-le : c’est un post honnête aussi.
Arrondis si tu préfères (« un peu plus de 2 000 € »), mais ne gonfle jamais un chiffre : quelqu’un finira par recouper, et un compte de build in public vit de sa crédibilité.
Tu peux aussi éviter d’oublier un palier : les automatisations de Hypepen préparent un brouillon quand ton MRR Stripe franchit le seuil que tu as choisi, ou quand tu publies une release GitHub. Le brouillon attend ta validation.
Releases : montrer ce qui change pour l’utilisateur
Une release se raconte du point de vue de celui qui l’utilise : le problème réglé, avant et après, puis le détail technique pour ceux qui le veulent.
« Nouvelle version 2.4 disponible » ne donne aucune raison de s’arrêter. « Tu peux maintenant [faire X] sans [corvée Y] » en donne une. Garde la liste exhaustive des changements pour ton journal des modifications, et choisis un seul changement pour le post.
Avant, pour [tâche], il fallait [étapes pénibles]. Depuis aujourd’hui, dans [produit] : [ce qui se passe maintenant, en une phrase]. Pourquoi on l’a fait : [ce que des utilisateurs ont dit ou ce que tu as observé]. [Capture ou courte vidéo du nouveau parcours]
Une capture ou une vidéo vaut mieux qu’une description : X prédit aussi l’agrandissement d’une photo et l’ouverture d’une vidéo.
Le lien vers ton produit peut aller dans le post : X dit ne pas pénaliser les liens. Pour garder le post lisible, tu peux aussi le mettre dans une réponse juste dessous.
Échecs et décisions difficiles
Les posts d’échec sont souvent les plus utiles de ta série, à condition d’en tirer une leçon précise plutôt qu’une confession.
Un lancement raté, une fonction que personne n’utilise, un prix trop bas : ces sujets intéressent parce que tout le monde les vit et peu les racontent. La structure qui marche : ce que tu pensais, ce qui s’est passé, ce que tu fais différemment.
J’ai passé [durée] sur [fonction ou projet]. [Résultat honnête, ex. : presque personne ne s’en sert]. Ce que je croyais : [hypothèse]. Ce que les données disent : [observation]. La leçon que je garde : [règle concrète que tu appliqueras].
Pas de reproche à un client ou à un concurrent : le signalement et le blocage sont les signaux les plus négatifs du classement de X.
Quelles métriques suivre
Suis les métriques de ton produit pour tes posts, et les métriques de X pour savoir quels posts méritent une suite.
| Métrique | Ce qu’elle te dit | Ce que tu en fais |
|---|---|---|
| MRR et clients actifs | Où en est le produit | Matière des bilans et des paliers |
| Taux de désabonnement | Si la valeur tient dans le temps | Post d’échec ou de correction |
| Réponses par post | Si le sujet fait réagir ta niche | Refaire un post sur le même pilier |
| Abonnements gagnés par post | Si le post donne envie de te suivre | Repérer les sujets qui recrutent |
| Impressions | La portée brute | Comparer à ta médiane, pas à celle des autres |
MRR et clients actifs
- Ce qu’elle te dit
- Où en est le produit
- Ce que tu en fais
- Matière des bilans et des paliers
Taux de désabonnement
- Ce qu’elle te dit
- Si la valeur tient dans le temps
- Ce que tu en fais
- Post d’échec ou de correction
Réponses par post
- Ce qu’elle te dit
- Si le sujet fait réagir ta niche
- Ce que tu en fais
- Refaire un post sur le même pilier
Abonnements gagnés par post
- Ce qu’elle te dit
- Si le post donne envie de te suivre
- Ce que tu en fais
- Repérer les sujets qui recrutent
Impressions
- Ce qu’elle te dit
- La portée brute
- Ce que tu en fais
- Comparer à ta médiane, pas à celle des autres
Compare chaque post à la médiane de tes propres posts, jamais à un compte plus gros : c’est la seule comparaison qui te dit si un sujet a marché. Le guide gagner des abonnés sans tricher détaille comment lire ce qui te fait suivre.
Les erreurs qui usent ton audience
- Le même post de palier copié tous les mois : X interdit les posts identiques ou très proches répétés.
- Les appâts (« like si tu veux la suite », « RT pour le lien ») : ils fatiguent, et les règles de portée de Hypepen les repèrent.
- Les chiffres invérifiables ou arrondis à l’avantage : une fois découverts, ils coûtent plus que dix bons posts.
- Les fils de dix posts pour une seule idée : un post long ou trois posts suffisent. Pour découper proprement, utilise le découpeur de thread.
- Ne parler qu’aux autres fondateurs : si ton produit vise des clients, parle aussi de leurs problèmes, pas seulement de tes métriques.
Pour d’autres structures réutilisables, va voir les modèles de posts X.
Questions fréquentes
Faut-il partager son MRR exact ?
Non. Un chiffre arrondi suffit pour raconter une progression. Ce qui compte, c’est la cause du changement et la décision qui suit. Ne publie jamais un chiffre gonflé.
Le build in public marche-t-il pour un produit qui n’a pas encore de clients ?
Oui : avant les clients, tu racontes le problème, tes entretiens, tes choix de cible et de prix. Ce sont souvent les posts qui attirent tes premiers utilisateurs.
Combien de posts par semaine ?
Un post de progrès par semaine et un bilan par mois sont un rythme tenable. Ajoute les événements quand ils arrivent, et réponds aux autres entre deux posts.
Peut-on automatiser les posts de build in public ?
On peut préparer automatiquement un brouillon quand un événement arrive (palier de revenu, nouvelle version), à condition de le relire et de le valider. X interdit les posts dupliqués et l’automatisation agressive.