Construire en public : comment l’écriture et la création de contenu sont devenus une stratégie de carrière tech

Il existe quelque part un développeur plus employable que vous — non pas parce qu’il code mieux, mais parce que les gens savent qu’il existe. Il partage ce qu’il construit. Il écrit sur ce qu’il apprend. Il publie ses échecs autant que ses succès. Et pourtant, les recruteurs glissent dans ses messages privés, les organisateurs de conférences l’invitent à intervenir, et des entreprises lui proposent des postes sans qu’il ait soumis une seule candidature.

C’est le mouvement du « build in public », et en 2026, il est devenu l’un des leviers de carrière les plus puissants à la disposition des professionnels de la tech dans le monde entier.

Ce que « construire en public » signifie réellement

Construire en public, c’est la pratique qui consiste à partager son travail, son processus, ses échecs et ses apprentissages de manière ouverte — sur des plateformes sociales, des newsletters, des blogs ou GitHub — au fur et à mesure que l’on avance, et non pas une fois que le résultat est poli et prêt à être montré. C’est l’opposé de la culture d’entreprise qui consiste à tout garder secret jusqu’au jour du lancement.

Le concept a pris de l’ampleur dans la communauté des indie hackers vers 2018–2020, quand des développeurs solo comme Pieter Levels ont commencé à partager en temps réel leurs graphiques de revenus, leurs décisions de code et leurs échecs produit. Levels a construit Nomad List et Remote OK en tweetant chaque étape et chaque recul. Il a transformé la transparence en audience, et cette audience en une activité valant plusieurs millions.

Mais construire en public n’est plus réservé aux fondateurs solo. C’est devenu une stratégie de carrière courante pour les ingénieurs, les designers, les chefs de produit et les data scientists qui travaillent au sein d’entreprises. Le signal est simple : si les gens peuvent voir votre façon de penser, votre goût et votre constance, vous n’avez pas besoin d’un CV pour attirer des opportunités.

Swyx et le cadre du « Learn in Public »

En 2018, l’ingénieur et auteur Shawn Wang — connu sous le nom de swyx — a publié un court essai intitulé « Learn in Public » qui a discrètement transformé la vision de milliers de développeurs sur l’évolution de carrière. Son argument central : quelle que soit la chose que vous apprenez, créez la ressource que vous auriez aimé trouver. Rédigez l’article de blog. Enregistrez le tutoriel. Postez le thread. Faites-le mal au début. Publiez quand même.

La logique est celle des intérêts composés. Chaque contenu que vous publiez est un artefact permanent qui travaille pour vous pendant que vous dormez. Un article de blog expliquant comment vous avez résolu un problème réseau Kubernetes délicat sera lu par des ingénieurs confrontés au même problème pendant des années. Un thread sur X résumant votre approche d’un entretien de conception système sera partagé des centaines de fois. Chaque artefact élargit votre surface de contact avec la chance.

Le cadre de swyx ne demande pas d’être un expert. Il demande d’avoir une longueur d’avance sur quelqu’un qui bute sur ce que vous venez de comprendre. C’est suffisant. La personne qui écrit pour les débutants pendant qu’elle est encore débutante a une avance considérable sur celle qui attend de se sentir légitime.

Des exemples réels qui ont transformé des carrières

Le schéma de l’accélération de carrière par le contenu est bien documenté. Marc Lou, un développeur français, a conçu et lancé plus de 15 petits projets SaaS tout en publiant chaque étape sur X. Sa transparence sur les revenus, le churn et l’architecture de son code lui a bâti une audience de plus de 100 000 abonnés et généré des ventes de produits dépassant tous les salaires qu’il avait jamais perçus.

Josh Comeau, ancien développeur chez Khan Academy et Gatsby, a commencé à rédiger des articles de blog très techniques et interactifs sur CSS et React. La qualité et la régularité de son écriture ont conduit à une activité de formation générant plusieurs millions de dollars par an et à une marque personnelle qui rivalise avec des entreprises dotées de départements marketing entiers.

À une échelle plus modeste, des centaines de développeurs rapportent avoir décroché leur poste actuel parce qu’un responsable du recrutement ou un CTO a vu un dépôt GitHub spécifique, un article LinkedIn ou un post Dev.to. Un tweet expliquant une solution ingénieuse peut atteindre la bonne personne au bon moment. Ce n’est pas de la chance — c’est de la surface d’exposition. Plus vous publiez, plus vous avez de chances d’être trouvé.

Les plateformes qui comptent en 2026

Le paysage des plateformes a évolué. En 2026, les canaux les plus efficaces pour les professionnels de la tech sont les suivants :

X/Twitter reste le canal de distribution le plus rapide pour les idées techniques courtes, les mises à jour produit et les prises de position. L’algorithme récompense la régularité et l’engagement, et la communauté tech y est encore très concentrée malgré la fragmentation.

LinkedIn est silencieusement devenu un territoire sérieux pour les contenus techniques de fond. Des ingénieurs qui le considéraient comme un simple site de recrutement découvrent que des posts réfléchis sur des décisions d’architecture, la dynamique d’équipe ou les leçons de carrière atteignent des centaines de milliers de vues sans presque aucun abonné préalable.

Substack et les newsletters offrent la relation la plus durable avec une audience. Les abonnés email ne dépendent pas des changements d’algorithme. Une newsletter avec 2 000 abonnés engagés dans un domaine technique de niche pèse davantage dans une carrière que 20 000 abonnés passifs sur Twitter.

Dev.to et Hashnode servent d’archives consultables pour les tutoriels techniques. Un article bien référencé sur un problème lié à un framework spécifique générera un trafic organique régulier pendant des années.

GitHub lui-même est un portfolio. Un profil bien entretenu avec des dépôts actifs, des READMEs clairs et des commits publics est la version silencieuse du build in public — visible par tous les recruteurs qui vous recherchent.

Comment commencer sans audience

L’erreur la plus fréquente est d’attendre d’avoir quelque chose « qui vaut la peine d’être dit ». Vous n’avez pas besoin de 10 ans d’expérience. Vous avez besoin d’une seule idée, d’un problème que vous venez de résoudre, d’une observation sur votre domaine qui pourrait être utile à quelqu’un d’autre.

Commencez par vous engager sur la régularité plutôt que sur la qualité. Publiez un contenu par semaine pendant trois mois. Peu importe si dix personnes le lisent. Ce qui compte, c’est de développer l’habitude, la voix d’écriture et la bibliothèque de travaux passés. L’audience suit la bibliothèque, pas l’inverse.

Choisissez une plateforme et allez en profondeur avant de vous disperser. Un développeur qui publie chaque jour sur LinkedIn pendant six mois surpassera celui qui publie sporadiquement sur cinq plateformes.

Documentez avant d’enseigner. Si vous n’êtes pas prêt à expliquer quelque chose, documentez-le plutôt — « voici ce que j’ai essayé, voici ce qui s’est passé, voici ce que je cherche encore à comprendre ». Ce type de narration honnête est souvent plus engageant que des tutoriels soignés.

Les métriques qui comptent vraiment

Les métriques de vanité — nombre d’abonnés, likes, impressions — sont de mauvais indicateurs d’impact sur la carrière. Les métriques qui comptent vraiment sont : les opportunités entrantes (offres d’emploi, demandes de collaboration, invitations à des conférences), les abonnés email et la qualité des réponses et des conversations que génère votre contenu.

Un développeur avec 800 abonnés newsletter dans la niche de la sécurité cloud sera remarqué précisément par les entreprises qui recrutent pour des rôles liés à la sécurité cloud. Les audiences de niche avec une forte intention valent plus que de grandes audiences passives.

Les risques et comment les gérer

Construire en public comporte de vrais risques. Partager un travail en cours peut exposer une pensée incomplète à des critiques. Parler de la stack technique de votre employeur peut créer des problèmes juridiques ou de réputation — vérifiez toujours votre contrat de travail et évitez de divulguer des informations propriétaires.

Il y a aussi le risque de l’épuisement. La création de contenu est un vrai travail. Une production durable vaut mieux qu’un démarrage en trombe suivi de six mois de silence. Traitez-le comme une routine de fitness, pas comme un sprint.

Le plus grand risque, cependant, est de ne pas construire en public du tout. Dans un marché où l’IA comprime la valeur perçue des compétences techniques génériques, les professionnels qui sont connus — qui ont un historique visible de pensée et de construction — sont ceux qui restent irremplaçables.

Sources et lectures complémentaires

• Learn in Public — Shawn Wang (swyx.io)
• Pieter Levels — Building in Public (levels.io)
• How I Built a Thriving Developer Blog — Josh Comeau
• The Build in Public Playbook for Developers — Indie Hackers
• Newsletters techniques sur Substack — Substack Discover