Il y a un fossé entre savoir écrire du code et savoir construire un logiciel que d’autres vont réellement utiliser. La plupart des environnements professionnels ne le font jamais franchir : on y travaille sur un périmètre fermé, sur une stack imposée, pour un nombre d’utilisateurs connus et captifs. L’open-source, lui, expose à la totalité du métier d’un seul coup : la technique, mais aussi le produit, la qualité, la communication, et le simple fait d’être confronté au jugement du monde entier. C’est, à mes yeux, le meilleur terrain de jeu pour progresser en tant que Software Engineer.
Sa force tient à une caractéristique rare : chacun peut y relever des défis à son propre rythme, en choisissant son niveau d’engagement et les sujets sur lesquels il veut grandir. Voici les cinq dimensions sur lesquelles il m’a fait, et continue de me faire, progresser.
Monter en compétences sur des sujets hors de portée au quotidien
Le cadre professionnel est par nature contraint : on utilise les technologies que le contexte impose, rarement celles que l’on rêve d’explorer. L’open-source lève cette limite. Vous voulez comprendre comment fonctionne un parser ? Lancez-vous en Rust. La sécurité applicative vous attire ? Des projets comme NodeSecure offrent un point d’entrée concret. Vous voulez toucher au frontend comme au backend ? Rien ne vous en empêche.
La clé est de cibler judicieusement. L’open-source n’est pas une fuite en avant technologique : c’est l’occasion de choisir délibérément les sujets et les stacks sur lesquels vous voulez réellement gagner en profondeur, puis de vous y confronter sur du code qui compte.
Collaborer avec les meilleurs, sur des projets à fort impact
C’est sans doute le bénéfice le plus sous-estimé. Travailler en open-source, c’est se retrouver, directement ou indirectement, au contact des meilleurs ingénieurs au monde, sur des projets à très fort impact.
Pour moi, Effect a été et reste cette opportunité : échanger et collaborer avec la crème de la crème de l’écosystème TypeScript, des core contributors TypeScript jusqu’à la core team Effect. On n’apprend pas la même chose en lisant du code d’exception qu’en écrivant son propre code dans son coin. Être exposé à ce niveau d’exigence, voir comment les meilleurs raisonnent, conçoivent et tranchent, c’est une accélération qu’aucune formation ne reproduit.
Avoir un impact réel, à grande échelle
Construire quelque chose d’utile, et le voir utilisé par des milliers de personnes que vous ne rencontrerez jamais, change le rapport au métier. skott, l’outil sur lequel je travaille depuis plusieurs années, est aujourd’hui téléchargé entre 30 000 et 40 000 fois par semaine, de l’ordre de 140 000 téléchargements par mois, et utilisé partout dans le monde.
Au-delà des chiffres, ce qui marque, ce sont les remerciements : des gens qui prennent le temps de me dire que l’outil leur a été utile. Apporter de la valeur à une infinité de personnes, parfois avec quelques centaines de lignes de code, c’est une satisfaction d’un autre ordre que de livrer une feature de plus dans un backlog.
Développer ses compétences Product et Marketing
On résume souvent l’open-source à de la technique pure. C’est une erreur. Même si les possibilités lucratives restent limitées, un projet open-source est aussi un terrain d’apprentissage pour deux compétences que les ingénieurs négligent trop souvent : le produit et le marketing.
Un projet, c’est un produit. Il faut savoir le mettre en valeur, expliquer ce qu’il résout, soigner sa documentation et son onboarding. Et il faut savoir en parler : faire connaître le projet, en augmenter l’adoption, aller chercher ses premiers utilisateurs. Ce sont des muscles que la plupart des environnements professionnels n’exercent jamais chez un développeur, et que l’open-source vous force à développer si vous voulez que votre travail rencontre son public.
S’exercer au Craftsmanship, à l’Agile et au Lean
Les consommateurs de projets open-source sont exigeants, bien plus qu’un utilisateur interne captif. La qualité du projet n’est pas optionnelle : elle conditionne directement l’adoption, et plus encore la capacité à attirer des contributions.
Vous voulez que votre projet soit utilisé ? Il faut cibler précisément le besoin, itérer efficacement et maintenir un haut niveau de satisfaction utilisateur. Concrètement, cela veut dire ajouter rapidement une feature très demandée, ou livrer un correctif critique sans traîner. Cette pression saine est un excellent moteur de discipline.
skott a ainsi été pour moi le meilleur terrain pour pratiquer en continu le Test-Driven Development, beaucoup de refactoring et une vraie agilité au quotidien. Le résultat parle de lui-même : zéro bug. Les seules issues remontées correspondent en réalité à des fonctionnalités pas encore développées, jamais à des régressions. C’est ce niveau d’exigence, imposé par la nature même du projet, qui tire la qualité vers le haut.
Les effets de bord qui surprennent
L’open-source réserve aussi des surprises. Si on m’avait dit que j’aurais l’occasion de présenter skott sur la scène internationale, je n’y aurais probablement pas cru. Ces effets de bord (visibilité, opportunités, rencontres) ne se planifient pas, mais ils découlent naturellement du fait de construire en public, de manière sérieuse et constante.
En conclusion
À ceux qui managent des équipes techniques : encouragez vos ingénieurs à prendre part à ces sujets, donnez-leur le temps et l’espace de le faire. Ils en ressortiront meilleurs, sur la technique comme sur tout le reste.
Et à ceux qui écrivent du code au quotidien : prenez du temps pour explorer l’open-source. Activez votre curiosité sur les projets que vous utilisez chaque jour. Et n’hésitez pas à rendre open-source les petits outils que vous avez construits pour vous-même, ils pourraient bien être utiles à beaucoup d’autres. C’est souvent par là que tout commence.