Freelance, agence ou salarié : quel modèle pour votre premier développement

« On va prendre un freelance, ce sera moins cher. » C’est la phrase la plus fréquente au moment de lancer un premier développement, et elle repose sur une comparaison que personne n’a faite.

Sur douze mois, à volume de travail comparable, les trois modèles se tiennent. Le salarié coûte en charges, en matériel et en encadrement ce que le freelance et l’agence facturent en taux. L’écart n’apparaît pas la première année. Il apparaît la deuxième, quand on mesure ce qui reste dans l’entreprise une fois la personne partie.

Le coût réel, sans illusion#

Le salarié. Le coût employeur représente environ une fois et demie le salaire brut. S’y ajoutent le matériel, les licences, le recrutement — qui n’est ni gratuit ni rapide —, la formation, et un poste que personne ne budgète : le temps d’encadrement. Un développeur seul dans une entreprise qui n’a pas de culture technique consomme du temps de dirigeant, et ce temps a un prix. Les fourchettes de rémunération selon les profils et les régions font l’objet d’un article dédié.

Le freelance. Vous payez des jours travaillés, sans charge ni engagement, avec une souplesse réelle : on arrête quand on veut. En contrepartie, vous ne payez que ce qui est fait — donc rien pendant ses congés, et rien pour la veille, la documentation ou la reprise de l’existant, sauf à les commander explicitement.

L’agence. Le taux affiché est plus élevé, et il couvre autre chose : une équipe, donc une continuité ; une relecture du travail par un pair ; un remplacement en cas d’absence ; et une responsabilité contractuelle qui engage une structure et non une personne.

Ces trois lignes se valent à peu près. Elles ne répondent simplement pas à la même question.

Les trois questions qui décident réellement#

Qui détient la connaissance ? C’est l’actif le plus précieux d’un projet, et le moins visible. Il ne s’agit pas du code — il est là — mais de la raison pour laquelle il est ainsi : les cas particuliers du métier, les décisions écartées, les contraintes d’un client historique. Cette connaissance se loge par défaut dans la tête de celui qui produit. Si c’est un externe, elle part avec lui, sauf à avoir exigé qu’elle soit écrite.

Que se passe-t-il si la personne disparaît demain ? Congé maladie, démission, changement de mission. Le freelance ne se remplace pas — vous recommencez une recherche. L’agence remplace en interne, avec une perte de contexte. Le salarié unique ne se remplace pas non plus, et son absence arrête tout.

Qui répond quand ça casse ? Un contrat de prestation engage une structure, avec une assurance et un interlocuteur. Un freelance engage son patrimoine, ce qui est théorique en pratique. Un salarié, lui, n’engage rien : c’est l’entreprise qui porte le risque.

Le tableau que nous montrons à nos clients#

La dernière ligne est celle qui doit guider la décision, et c’est la seule qui ne figure jamais dans un comparatif de devis.

Les trois pièges#

Le développeur seul. C’est le montage le plus fragile des trois, et le plus fréquent dans les TPE. Personne ne relit son travail, personne ne conteste ses choix, personne ne le remplace en août. Il s’isole techniquement, l’entreprise devient dépendante d’une seule personne, et cette personne finit souvent par partir faute de perspective — en emportant tout. Si vous recrutez un premier développeur, prévoyez un regard extérieur régulier. Ce n’est pas de la défiance, c’est ce qui lui permet de progresser et à vous de dormir.

Le freelance moins cher. Un taux journalier bas ne dit rien du coût total. Un développement mené sans cadrage, sans relecture et sans documentation produit un logiciel qui fonctionne le jour de la livraison, et dont personne ne saura quoi faire dix-huit mois plus tard. La facture arrive alors sous forme de dette technique, qui se rembourse toujours.

L’agence dont on ne peut plus sortir. Le risque n’est pas la qualité, c’est la captivité : comptes à son nom, code sur son dépôt, aucune documentation d’exploitation. Trois lignes au contrat suffisent à l’éviter — comptes à votre nom, cession du code avec droit d’adaptation, documentation livrée. Nous y consacrons deux articles, sur la propriété du code et sur l’hébergement.

Ce qui marche le plus souvent en PME#

Ce n’est presque jamais un modèle pur.

La combinaison que nous voyons réussir associe une personne en interne — qui détient la connaissance métier et la relation aux utilisateurs, sans forcément écrire beaucoup de code —, un partenaire externe qui apporte la capacité de production et la continuité, et une direction technique à temps partagé pour arbitrer les choix structurants sans en supporter le coût à plein temps. C’est le rôle que nous décrivons dans notre article sur le CTO à temps partagé.

Chacun fait alors ce qu’il fait le mieux, et surtout : aucun n’est indispensable seul. C’est la seule propriété qui compte vraiment.

Quand recruter, vraiment#

Trois conditions, à réunir avant d’ouvrir un poste :

1. Le logiciel est devenu le produit, et non plus un support de l’activité.
2. Les évolutions sont continues, et non plus des projets espacés.
3. La connaissance métier accumulée constitue un avantage que vous ne voulez pas voir sortir.

Tant que ces trois conditions ne sont pas réunies, externaliser reste plus efficace — et surtout réversible. Recruter trop tôt coûte cher deux fois : une fois au recrutement, une fois à la séparation.