Choisir sa stack ou son marché du recrutement : la décision technique que vous prenez sans regarder qui vous pourrez embaucher

Un fondateur technique m’a montré fièrement son backend écrit en Elixir. Élégant, concurrent, taillé pour la charge. Six mois plus tard, il avait besoin de deux développeurs supplémentaires et n’en trouvait aucun à Lyon dans son budget. Sa stack était excellente. Son marché du recrutement, inexistant.

C’est l’angle mort le plus coûteux d’une décision d’architecture précoce : on l’évalue sur des critères techniques — performance, courbe d’apprentissage, écosystème — et presque jamais sur la seule question qui va vraiment vous ralentir dans dix-huit mois. Combien de personnes capables de travailler dessus sont recrutables, près de chez vous, dans votre fourchette de salaire ?

Une stack n’est pas qu’une décision produit, c’est une décision RH

Quand vous choisissez un langage et un framework, vous ne choisissez pas seulement comment votre produit sera construit. Vous choisissez la taille du vivier dans lequel vous allez pêcher pendant les cinq prochaines années, la vitesse à laquelle vous pourrez remplacer quelqu’un qui part, et le prix que le marché vous imposera pour chaque embauche.

Prenez la différence entre un backend Node/TypeScript et un backend Rust. Sur le papier, Rust gagne sur la robustesse et la performance. Dans les faits, à Paris, vous trouverez dix candidats Node solides pour un candidat Rust senior — et ce dernier vous coûtera 20 à 30 % de plus, parce que la rareté se paie. Multipliez ça par la durée d’un recrutement : un poste Node se pourvoit en quatre à six semaines, un poste Rust senior peut vous prendre trois à quatre mois. Ces mois-là, ce n’est pas du confort perdu, c’est du runway brûlé et une roadmap qui glisse.

Le raisonnement vaut aussi hors des langages « exotiques ». Choisir un framework front à contre-courant du marché local, un ORM confidentiel, une base de données de niche — chaque décision réduit mécaniquement le nombre de personnes qui peuvent contribuer sans une longue montée en compétence. Et en startup, le temps de montée en compétence, c’est de la vélocité que vous ne récupérerez jamais.

Le piège de la stack « optimale » choisie par le fondateur solo

Le scénario est presque toujours le même. Un fondateur technique construit le MVP seul. Il choisit ce qui l’amuse, ce qu’il maîtrise, ou ce qui est intellectuellement supérieur. À ce stade, c’est légitime : la vélocité d’une personne seule dépend surtout de son propre confort.

Le problème surgit au moment de passer de un à trois, puis à six développeurs. La stack qui maximisait la productivité d’un individu devient un frein au recrutement collectif. Le fondateur découvre alors qu’il a optimisé pour lui-même une décision qui aurait dû être optimisée pour l’équipe qu’il n’avait pas encore.

On voit ce pattern chez la startup qui a bâti tout son produit sur un framework porté par une seule communauté restreinte, et qui se retrouve dépendante de trois personnes dans tout le pays. On le voit aussi chez le fondateur qui a choisi une base de données spécialisée pour un besoin de performance qui n’existera qu’à la série B — et qui, en attendant, ne trouve personne pour l’administrer.

La vraie question n’est pas « quelle est la meilleure technologie ? » mais « quelle technologie me permet de recruter vite, à un coût soutenable, sans dépendre d’un vivier de trente personnes en France ? »

Ce que le marché francophone change à l’équation

Le marché du recrutement tech n’est pas mondial, il est local et fragmenté. Un vivier abondant dans la Silicon Valley peut être quasi vide à Nantes ou à Toulouse. Raisonner sur les tendances GitHub mondiales pour décider de votre stack, c’est confondre le marché théorique et le marché où vous allez réellement embaucher.

En France, quelques réalités structurent l’arbitrage. Les écoles d’ingénieurs et les formations forment massivement sur certains langages, ce qui crée des viviers profonds sur Java, Python, JavaScript/TypeScript et PHP. Les technologies plus récentes ou plus pointues restent portées par des communautés de niche, souvent concentrées à Paris. Si vous êtes en région et que votre modèle repose sur du recrutement local plutôt que 100 % remote, ignorer cette géographie du talent revient à vous tirer une balle dans le pied.

Le télétravail élargit le vivier, mais ne l’efface pas. Recruter en full remote sur toute la francophonie augmente vos options, au prix d’une complexité de management et parfois d’une concurrence salariale accrue avec des acteurs mieux financés. C’est une variable à intégrer consciemment, pas un joker qui annule le problème.

Enfin, gardez en tête que votre stack devient un argument d’attractivité — dans les deux sens. Une stack moderne et bien tenue attire des profils curieux et exigeants. Une stack perçue comme datée ou marginale fait fuir les meilleurs. L’attractivité employeur passe aussi par ce que votre package.json raconte de vous.

Ce qu’il faut vraiment faire, selon votre stade

Avant d’écrire la première ligne de code destinée à survivre, posez-vous trois questions dans cet ordre : qui vais-je devoir recruter dans les dix-huit mois, où, et à quel coût ? La réponse doit peser autant que les benchmarks de performance.

En pre-seed, privilégiez sans complexe le mainstream. TypeScript, Python, un framework front dominant, une base de données relationnelle éprouvée. L’objectif n’est pas l’élégance, c’est de pouvoir recruter n’importe qui de compétent rapidement, et de ne jamais être bloqué par la rareté. Vous n’avez pas encore validé que votre produit mérite une stack sophistiquée ; ne payez pas la dette de recrutement d’un choix prématuré.

En seed, vous commencez à structurer une équipe. C’est le moment d’accepter une ou deux exceptions ciblées à la règle du mainstream, mais uniquement là où un besoin réel et documenté le justifie — un service de traitement de données lourd, une brique temps réel. Isolez ces choix pointus dans des composants circonscrits, pas dans le cœur du produit que toute l’équipe doit toucher au quotidien. Vous limitez ainsi la dépendance à des profils rares.

En série A, votre pouvoir d’attraction et votre budget augmentent. Vous pouvez désormais assumer des choix plus exigeants, parce que vous avez de quoi payer la rareté et une marque employeur qui attire. Mais vérifiez que ces choix résolvent un vrai problème d’échelle, et pas seulement une envie d’ingénierie. La discipline du pré-seed reste une bonne boussole : ce qui coûte cher à recruter doit rapporter proportionnellement en valeur produit.

Dans tous les cas, faites une chose simple et trop souvent oubliée : avant de figer une techno, ouvrez trois jobboards, filtrez sur votre ville ou votre zone de recrutement, et comptez les CV réellement disponibles. Regardez les fourchettes salariales pratiquées. Cette recherche de vingt minutes vous en apprendra plus sur la viabilité de votre stack que n’importe quel comparatif technique.

La bonne stack, c’est celle que vous pouvez faire grandir avec des gens

La meilleure technologie n’est pas la plus performante ni la plus à la mode. C’est celle qui vous laisse recruter au rythme de votre croissance, remplacer un départ sans crise, et faire monter une équipe sans dépendre de trois experts introuvables. La performance se rattrape avec de l’optimisation ; un vivier de recrutement vide, non.

Cela ne veut pas dire choisir la stack la plus banale par défaut. Cela veut dire faire de la disponibilité du talent un critère de décision explicite, au même titre que la scalabilité — et arbitrer consciemment chaque exception à cette règle.

Alors avant votre prochain choix d’architecture, posez-vous cette question inconfortable : si votre lead dev démissionnait demain, combien de temps vous faudrait-il pour le remplacer sur cette stack, dans votre budget ? Si la réponse dépasse trois mois, vous n’avez pas choisi une technologie. Vous avez choisi une dépendance.