Recrutement développeur : externaliser ou internaliser ?

Un fondateur m'a demandé s'il devait recruter un CTO. Mon premier réflexe a été de lui dire non.

Pas parce qu'il n'avait pas besoin de tech — il avait une app en production, 300 utilisateurs, du revenu. Mais parce qu'à son stade, recruter à 80K€/an était le meilleur moyen de cramer sa trésorerie sans accélérer son produit. Il avait besoin de quelqu'un qui pilote la tech. Pas de quelqu'un qui code à temps plein.

C'est la question que je vois mal posée le plus souvent chez les fondateurs non-techniques. Pas "comment recruter un développeur", mais est-ce que je dois en recruter un maintenant ? Et si oui, lequel, dans quel modèle.

Pourquoi la question se pose différemment en 2026

Il y a trois ans, c'était simple. Vous vouliez un produit tech ? Vous recrutiez un dev ou vous passiez par une agence. Deux options, point.

Le paysage a explosé. Le vibe coding — Lovable, Bolt, Cursor — permet à un fondateur de produire un MVP sans écrire une ligne de code. Les freelances se trouvent en 48h sur des plateformes. Les CTO externes proposent du pilotage technique sans engagement long terme. Plus il y a d'options, plus la confusion grandit.

J'accompagne des fondateurs chaque semaine. La moitié arrivent avec la mauvaise question : "Je dois recruter combien de devs ?" Alors que la vraie question, c'est : quel modèle tech est adapté à mon stade ?

Les 3 modèles et leurs limites

Tout externaliser

Freelances, agences, prestataires. Aucun salarié tech en interne.

Quand ça marche : avant le product-market fit. Votre produit va changer, pivoter, peut-être mourir. Payer un freelance 400-600€/jour pendant 3 mois coûte entre 25 000 et 40 000€. Un CTO salarié sur la même période : 25-30K€ de salaire + charges, avec un engagement moral, des parts à négocier, et un licenciement complexe si ça ne colle pas.

Un client m'a contacté après avoir fait l'inverse. Il avait recruté un CTO et un dev junior avant même d'avoir validé son idée. Budget : 130K€/an de masse salariale. Six mois plus tard, pivot. Le CTO a démissionné — la nouvelle direction ne l'intéressait pas. Le code ? À la poubelle. 65K€ de salaires pour du code qui n'a jamais vu un vrai utilisateur.

Les limites : la coordination. Une startup SaaS que j'ai accompagnée avait fait appel à 3 freelances en 18 mois. Aucun ne connaissait le code de l'autre. Chaque nouveau passait 2 semaines à comprendre avant de produire une seule ligne utile. Au bout de 18 mois, le fondateur avait dépensé autant qu'un salarié — sans la continuité.

L'autre piège, c'est l'agence. Un fondateur m'a montré ses factures : 60K€ pour le MVP, puis 5K€/mois de maintenance et évolutions. Dix-huit mois plus tard, 150K€ au total. Chaque modification nécessitait un devis. Il n'avait aucun contrôle sur son propre produit. Pour comprendre pourquoi ces chiffres sont typiques, j'ai détaillé les vrais coûts de développement en 2026.

Tout internaliser

Recruter votre propre équipe : CTO, développeurs, designer.

Quand ça marche : après le product-market fit, quand votre produit est votre avantage compétitif et que vous itérez tous les jours. Une équipe interne connaît le produit, le marché, les utilisateurs. Elle prend des décisions plus vite qu'un prestataire parce qu'elle vit le produit au quotidien.

Le risque, c'est le mauvais recrutement. Un fondateur a embauché un "CTO" — en réalité un dev senior — avec 10% de parts. Le profil était bon techniquement, mais il a fait des choix d'architecture dimensionnés pour Netflix : microservices, Kubernetes, 3 bases de données différentes. Pour 50 utilisateurs. L'infra est passée de 50€ à 800€/mois. Huit mois et 4 refactorisations plus tard, le fondateur a compris que recruter un CTO ne signifie pas recruter le bon CTO. Si vous décidez d'internaliser, j'ai écrit un guide complet pour recruter un développeur quand on n'est pas technique.

Le modèle hybride

C'est le modèle que je recommande le plus souvent entre le MVP validé et la série A. Je suis transparent : c'est aussi ce que je propose en tant que CTO externe, donc prenez mon avis avec ce biais en tête. Mais si je le recommande, c'est parce que je vois les résultats.

Le principe : un CTO externe qui pilote l'architecture, les choix techniques et le recrutement, combiné avec un ou deux devs internes — souvent juniors — qui exécutent. Le CTO externe apporte l'expérience à temps partiel. Les devs internes apportent la continuité et la connaissance produit.

Un cas concret. Un fondateur avec qui j'ai travaillé 18 mois. Budget : 3K€/mois de CTO externe + un dev junior à 35K€/an. En 12 mois : produit stable, 2 000 utilisateurs, due diligence technique passée sans accroc, levée bouclée. Le dev junior est monté en compétence, j'ai progressivement réduit mon intervention. Le fondateur n'a jamais eu à gérer seul un sujet technique qu'il ne comprenait pas.

La limite : ça ne marche que si le CTO externe est vraiment impliqué dans le produit, pas juste un consultant qui passe 2 heures par mois. Et quand l'équipe dépasse 4-5 devs, il faut un CTO interne à temps plein. Le modèle hybride est un pont, pas une destination.

L'arbre de décision : 4 questions pour trancher

Plutôt qu'une matrice théorique, voici les 4 questions que je pose systématiquement.

Question 1 — Avez-vous trouvé votre product-market fit ?

Non → Externalisez. Ne recrutez personne tant que vous ne savez pas si votre produit intéresse le marché. Chaque euro dépensé en salaire avant le PMF est un euro que vous ne pourrez pas réinvestir après le pivot. Utilisez le vibe coding ou un freelance pour valider vite et pas cher.

Oui → Question 2.

Question 2 — Quel est votre budget tech annuel ?

• Moins de 80K€ → Externalisez ou hybridez. Vous n'avez pas les moyens d'un recrutement salarié quand on intègre les coûts réels (voir section suivante).
• Entre 80K€ et 200K€ → Modèle hybride. CTO externe + 1-2 devs internes. Vous construisez votre équipe sans la surdimensionner.
• Plus de 200K€ → Internalisation possible. Vous avez le budget pour recruter un vrai CTO et constituer une équipe.

Question 3 — Votre produit tech est-il votre avantage compétitif ?

Oui (SaaS, marketplace, fintech) → L'internalisation est indispensable à terme. Votre tech est votre produit. Confier votre avantage concurrentiel à un prestataire, c'est comme sous-traiter votre recette secrète.

Non (e-commerce, service avec app, outil interne) → L'externalisation ou l'hybride peuvent durer. Si votre tech est un outil au service du business et pas le business lui-même, pas besoin d'une armée de devs.

Question 4 — À quelle vitesse changez-vous ?

• Moins de 2 releases par mois → Externaliser suffit. Le rythme est assez lent pour qu'un prestataire suive.
• 2-4 releases par mois → Hybride. Vous avez besoin de quelqu'un en interne qui connaît le code au quotidien.
• Plus de 4 releases par mois → Internalisez. À ce rythme, le coût de coordination avec l'extérieur dépasse le coût de management d'une équipe interne.

Ce que coûte vraiment un recrutement développeur

Je vois régulièrement des fondateurs raisonner uniquement en salaire brut. "Un dev junior à 40K€, ça rentre dans mon budget." Sauf que 40K€ brut, ce n'est pas 40K€ de dépense.

Décomposition réelle en 2026 :

• Salaire brut : 40-75K€ selon le niveau
• Charges patronales (+42 à 45%) : un brut de 50K€ devient 72K€ pour l'employeur
• Outils, licences, infra : 2-5K€/an
• Recrutement (cabinet, temps passé, tests) : 5-15K€, amortis sur 2 ans si tout va bien
• Onboarding : 1-2 mois à productivité réduite — du temps, pas que de l'argent
• Management : 10-20% du temps d'un manager ou du fondateur

Au total, un dev junior affiché à 40K€ brut coûte 70 à 80K€/an. Un dev senior à 65K€ brut : 100 à 130K€/an.

Et le risque. Les stats de la tech donnent environ 1 embauche sur 3 qui ne passe pas la période d'essai. Un recrutement raté, c'est 3-4 mois de perdus et 15-20K€ évaporés. C'est pour ça que la question n'est pas juste "est-ce que je peux payer un dev" — c'est "est-ce que je peux absorber un recrutement raté ?"

La transition : de l'externe vers l'interne sans crash

Le moment le plus dangereux, c'est la bascule. Vous avez externalisé, ça fonctionne, et vous voulez internaliser. Si vous ratez cette transition, vous perdez la connaissance accumulée par vos prestataires sans que votre équipe interne soit prête.

Ne coupez pas l'externe avant que l'interne soit autonome. Prévoyez 2-3 mois de chevauchement. Le freelance ou le CTO externe transmet, documente, forme. Votre nouvelle recrue monte en compétence sur le code existant avant de voler de ses propres ailes. J'ai vu trop de fondateurs couper le prestataire le jour où le salarié arrive — résultat : 3 mois à comprendre un code que personne ne peut expliquer. Si vous êtes dans cette situation, la méthode pour reprendre un code existant sans y laisser des plumes vous évitera les erreurs classiques.

Faites auditer avant de recruter. Un audit de code avant de lancer le recrutement vous évite de mettre un dev sur une codebase non maintenable. Si la dette technique est trop lourde, votre nouvelle recrue va fuir en 6 mois. J'ai vu le scénario se répéter 3 fois chez un même client — 3 devs recrutés, 3 départs en moins d'un an — avant qu'il accepte de stabiliser le code d'abord.

Ce que je conseillerais si vous lisez cet article

Si vous cherchez "recrutement développeur" sur Google, il y a de fortes chances que vous soyez à un moment charnière. Le produit tourne, les freelances coûtent cher, et vous sentez qu'il faut structurer.

Ne commencez pas par recruter. Posez-vous les 4 questions ci-dessus. Si la réponse est "internaliser", faites-le dans le bon ordre : d'abord un audit du code existant, puis un cadrage technique avec quelqu'un d'expérimenté, puis le recrutement avec une personne technique dans la boucle pour valider les candidats.

Si vous n'avez pas de directeur technique pour piloter tout ça, c'est exactement le rôle d'un CTO externe : vous accompagner de la décision externaliser/internaliser jusqu'au moment où votre équipe est autonome.