Freelance ou salarié pour son premier développeur ?

« Je prends un freelance pour aller vite, ou je recrute tout de suite ? » La question arrive presque toujours au même moment : le produit doit avancer, le prestataire ne suffit plus, et un fondateur non technique doit décider seul d'une forme de contrat dont il mesure mal les conséquences. On la traite souvent comme une question de budget. C'est d'abord une question de durée, et de ce que vous voulez garder dans l'entreprise quand la personne partira.

Pour son premier développeur, un freelance accélère quand le périmètre est court et clair : il démarre en quelques semaines et s'arrête sans procédure. Un salarié s'impose dès que le produit devient un actif à faire vivre, parce qu'il capitalise la connaissance et reste. Le bon choix dépend de la durée du besoin et de qui relira le travail.

La construction de l'équipe dans son ensemble est traitée dans le guide pour construire son équipe tech et produit. Si votre question porte sur la direction technique plutôt que sur le développement, voyez CTO freelance, fractionnel ou CDI, et pour le choix entre une agence et une équipe interne, internaliser ou externaliser le développement. Ici, on parle du premier développeur, celui qui écrira le code tous les jours.

Ce que chaque option vous achète vraiment

Un freelance et un salarié peuvent avoir exactement le même niveau et écrire le même code. Ce que vous achetez diffère pourtant, et c'est cette différence qui doit guider le choix, pas le montant sur la facture.

Les ordres de grandeur pour comparer

Les chiffres ci-dessous sont des fourchettes de marché en France pour un profil confirmé à senior en développement web ou mobile courant. Ils varient selon la stack, la ville et le passage éventuel par une plateforme qui prélève une commission.

Deux lectures s'imposent. D'abord, à temps plein et sur un an, l'écart de coût est bien plus faible qu'on ne l'imagine : un TJM ne se compare pas à un salaire brut, mais au coût complet d'un salarié, comme je le détaille dans combien payer un développeur freelance senior. Ensuite, la vraie différence est ailleurs : la vitesse et la souplesse d'un côté, la continuité de l'autre.

La ligne sur la propriété du code mérite une attention particulière. Un freelance est l'auteur de ce qu'il écrit, et sans clause de cession de droits précise dans son contrat, vous n'avez souvent qu'un droit d'usage. Les détails, et la clause à exiger, sont dans à qui appartient le code de mon app.

Quand le freelance accélère vraiment

Le freelance est le bon choix dans quatre situations que je rencontre souvent. Pour sortir une première version avant d'avoir la preuve que le produit trouve son marché : engager un CDI sur une hypothèse non validée, c'est prendre un risque que rien n'oblige à prendre. Pour une compétence pointue et bornée, comme un paiement en ligne, une intégration complexe ou une migration. Pour combler un trou pendant un recrutement, sans laisser le produit à l'arrêt trois mois. Et pour tester une collaboration avant de proposer un poste, ce qui rassure les deux côtés.

Dans ces quatre cas, trois conditions font la différence entre un freelance qui accélère et un freelance qui crée une dépendance : un périmètre écrit avec une date de fin, quelqu'un qui relit son travail (un pair technique, pas vous), et un code déposé dès le premier jour sur des comptes au nom de la société.

Quand le freelance coûte la continuité

Le coût du freelance ne se voit pas sur les factures. Il se voit le jour où il s'arrête. Un fondateur que j'accompagnais avait fait construire sa première version par trois freelances successifs, tous compétents. Aucun n'avait écrit pourquoi le produit était organisé ainsi, et le développeur salarié finalement recruté a passé ses deux premiers mois à reconstituer des décisions que personne ne pouvait plus expliquer.

Le signal qu'il est temps de basculer vers un salarié tient en quelques questions. Votre produit a-t-il des utilisateurs qui paient et une roadmap qui dépasse six mois ? Vous surprenez-vous à réexpliquer le même contexte à chaque nouvel intervenant ? Une levée de fonds approche-t-elle, avec une due diligence où l'on vous demandera qui détient la connaissance du produit ? Si vous répondez oui à l'une de ces questions, la continuité vaut désormais plus que la souplesse.

Organiser le passage de l'un à l'autre

Le parcours le plus sain se prépare dès la signature du freelance. Écrivez dans sa mission qu'une partie de son travail consiste à documenter ses choix et à préparer une passation, et prévoyez quelques jours de chevauchement avec la personne qui prendra le relais. Pendant ce temps, lancez le recrutement salarié sans vous presser, avec le processus décrit dans recruter son premier développeur sans être technique.

Parfois, le bon salarié est le freelance lui-même. Proposez-le franchement, mais vérifiez d'abord votre contrat : certaines plateformes et sociétés intermédiaires interdisent l'embauche directe ou la facturent. Et acceptez qu'un excellent freelance puisse ne jamais vouloir de CDI. Dans ce cas, ne forcez rien : organisez la continuité autrement, avec une documentation exigée, un code relu régulièrement et une seconde personne qui connaît le produit.