Pour un développeur, le personal branding, c’est être connu pour une stack précise par les gens qui vous recrutent ou vous achètent des prestations. On y arrive en publiant ce qu’on construit et ce qu’on apprend, à un rythme tenable. Et le rythme le plus facile à tenir, c’est le calendrier des versions des outils que vous utilisez déjà.
C’est quoi, le personal branding pour un développeur ?
Enlevez le vocabulaire marketing et il reste une idée simple. Quand quelqu’un de votre réseau cherche une personne qui connaît Python, ou qui a déjà fait la migration vers TypeScript 7, c’est votre nom qui lui vient à l’esprit. Rien de plus.
Beaucoup de développeurs n’aiment pas l’idée, et on les comprend. Ça sonne comme de l’autopromotion, les conseils autour sont pleins d’accroches et de « growth hacks », et un bon travail devrait parler de lui-même. Le problème, c’est qu’un bon travail dans un dépôt privé ne parle à personne. Expliquer comment vous avez corrigé une rupture de compatibilité, ce n’est pas vous vanter. C’est ce que vous écririez dans la description d’une pull request, pour un public plus large, et ça fait gagner un après-midi à la personne suivante.
Choisissez deux ou trois sujets dans votre vraie stack
Ne choisissez pas vos sujets pour la taille de leur audience. Prenez ceux que vous touchez chaque semaine : ce sont ceux dont vous pouvez parler sans recherche, et ceux où vous remarquerez ce qui change.
Une développeuse backend prendra peut-être Node.js, PostgreSQL et sa CI. Un profil data, Python, pandas et ses notebooks. Gardez la liste courte. Deux ou trois sujets suffisent pour que les gens associent votre nom à quelque chose. Avec dix, ils ne l’associent à rien.
Suivez le calendrier des versions
C’est ce qui rend la publication plus simple pour les développeurs que pour presque tout le monde : vos outils publient leur propre planning. Une nouvelle version vous donne une raison datée de publier, un sujet que les gens lisent déjà et un périmètre clair. Pas besoin d’idées. Il vous faut le changelog et une heure avec la nouvelle version.
Voici le mois que nous avons construit autour de nos quatre carrousels, avec des dates vérifiées sur la page officielle de chaque projet :
| Date | Ce qui se passe | Notre carrousel |
|---|---|---|
| Jeudi 1er octobre 2026 | Python 3.15.0 final (PEP 790, date prévue) | Cinq nouveautés utiles, en code |
| N’importe quelle semaine | AGENTS.md n’a pas de date de sortie : un sujet intemporel | Écrit une fois, lu par vos agents |
| Depuis le 8 juillet 2026 | TypeScript 7.0 est sorti (annonce) | Cinq choses qui ont cassé à la migration |
| Mardi 20 octobre 2026 | Node.js 24 passe en maintenance (calendrier) | |
| Mercredi 28 octobre 2026 | Node.js 26 devient LTS active | Ce que vous gagnez, ce qui casse |
Deux choses font que ça marche. La date vous donne une échéance, et c’est l’échéance qui fait qu’un post est fini. Et le post est utile le jour où les gens cherchent : la semaine où une version sort, c’est la semaine où ils veulent savoir ce qui casse.
Publiez quelques jours avant une sortie, pas après. Python publie des bêtas et des release candidates des mois avant la version finale, donc tout ce qui est sur le carrousel peut être testé à l’avance. C’est ce que nous avons fait : chaque extrait du carrousel Python a été exécuté sur une bêta de la 3.15 avant d’aller sur une slide.
Pour Node.js, la date utile est le passage en LTS, pas la première sortie. Le projet le dit sans détour : « Production applications should only use Active LTS or Maintenance LTS releases » (nodejs.org), autrement dit, en production, seulement des versions LTS actives ou en maintenance. Le calendrier des versions vous donne la date exacte de ce passage. Notre carrousel Node 26 sort entre le 20 octobre, quand Node 24 passe en maintenance, et le 28 octobre.
Entre deux sorties, prenez des sujets intemporels : un outil ou un format de fichier qui ne dépend pas d’une date. Pour nous, c’est AGENTS.md. Gardez-en un ou deux en réserve pour les semaines calmes.
Un rythme que vous pouvez tenir
Nous ne vous donnerons pas de chiffre de croissance d’abonnés. Nous n’en avons pas de fiable, et le vôtre dépendra plus de votre réseau que de votre rythme.
Ce que nous pouvons donner, c’est un conseil. Choisissez un rythme qui survit à un mois chargé. Pour la plupart des développeurs en poste, c’est au plus un carrousel par semaine, ou un par sortie dans votre stack. Rater une semaine ne coûte pas grand-chose. Abandonner après trois semaines d’un rythme intenable coûte tout ce que vous aviez commencé.
Fixer le format une fois pour toutes aide aussi. Si chaque post est un carrousel de 8 slides avec une couverture, les changements et une antisèche, votre temps va au contenu et pas à la mise en page. C’est pour ça que nos quatre carrousels se ressemblent.
Deux champs du profil qui transforment une visite en contact
Un bon post envoie des gens sur votre profil. Deux champs décident s’ils restent.
Le titre du profil. Pour LinkedIn, c’est « le texte qui s’affiche en dessous de votre nom dans l’introduction sur votre profil ». Il apparaît dans les résultats de recherche et peut être distinct de l’intitulé de votre poste actuel (aide LinkedIn). Mettez-y votre stack, pas seulement votre fonction. « Développeur backend, Node.js et PostgreSQL » en dit plus à un visiteur que « Senior Engineer » dans une entreprise qu’il ne connaît pas.
La section Sélection. LinkedIn permet d’y mettre en avant des posts que vous avez écrits, des articles publiés sur LinkedIn, et aussi des médias externes comme des images, des documents et des liens (aide LinkedIn). Mettez-y vos deux ou trois meilleurs carrousels : un visiteur voit votre travail avant votre parcours.
Quoi mesurer
Les statistiques d’un post LinkedIn donnent trois groupes de chiffres utiles ici (aide LinkedIn) :
- La découverte : le nombre d’affichages de votre post, et le nombre de membres et de pages distincts qui l’ont vu.
- L’activité sur le profil : les visites de profil venues de ce post, et les abonnés gagnés grâce à lui.
- L’engagement : réactions, commentaires, republications, enregistrements et envois sur LinkedIn.
Si le but est d’être connu pour votre stack, regardez les visites de profil et les abonnés gagnés par post plus que les réactions. Ils disent si le post a donné envie de savoir qui l’a écrit. Les enregistrements valent aussi le coup d’œil : on enregistre ce qu’on compte utiliser.
Deux réserves tirées de la même page d’aide. LinkedIn indique que ces chiffres sont des estimations et peuvent manquer de précision. Et sa liste des types de posts avec statistiques cite les posts texte, les images, les vidéos, les événements, les sondages et les articles, mais pas les documents : vérifiez ce que vos propres posts document affichent avant de vous fier à un chiffre.
Par où commencer
Prenez la prochaine sortie dans votre stack, lisez son changelog et essayez les changements qui vous concernent. Puis faites huit slides. Pour le format, voyez carrousel LinkedIn pour développeurs. Pour garder le code lisible sur mobile, voyez publier du code sur LinkedIn. Nous faisons Carouselr pour exactement ce genre de post.
