Recruter un développeur ou passer par un studio : le calcul que personne ne fait

La question revient à chaque fois, et elle est légitime : pourquoi payer un prestataire alors qu'on pourrait recruter quelqu'un ?

Le calcul qu'on fait spontanément est simple. Un développeur expérimenté coûte tant par mois. Un studio facture tant par jour. On multiplie, on compare, et le recrutement gagne largement.

Ce calcul n'est pas faux. Il est incomplet, et ce qu'il oublie représente souvent plus que ce qu'il compte.

Ce que le calcul oublie

Le délai avant d'avoir quelqu'un. Entre la décision et le premier jour, comptez trois à six mois sur un profil senior — rédaction, sourcing, entretiens, préavis. Pendant ce temps, le processus que vous vouliez outiller continue de tourner sur un tableur.

Le délai avant d'être productif. Un bon développeur n'est pas utile le premier jour. Il l'est quand il comprend votre métier : vos règles de gestion, vos cas particuliers, ce qui se passe en fin de mois. Sur un domaine dense — grande distribution, logistique, réglementaire — comptez plusieurs mois de plus.

Le coût complet. Le salaire brut n'est pas le coût. Il faut y ajouter les charges patronales, les congés payés, la mutuelle, le matériel, les licences, la formation, et une part de temps d'encadrement — parce qu'un développeur seul dans une entreprise qui n'en a pas d'autre a besoin de quelqu'un pour arbitrer.

Le risque de dépendance. C'est le poste le plus cher, et il n'apparaît dans aucun budget. Une seule personne écrit le code, connaît l'architecture, et sait pourquoi telle décision a été prise. Le jour où elle part — et elle partira, un jour — tout ce savoir sort avec elle. Vous ne recrutez pas un remplaçant : vous recommencez.

Les creux d'activité. Un projet logiciel n'a pas une charge constante. La conception et le lancement demandent beaucoup, la maintenance beaucoup moins. Un salarié coûte le même prix dans les deux phases.

Le vrai calcul

Il ne s'agit pas de comparer un salaire à un tarif journalier, mais deux scénarios complets sur trois ans.

Côté recrutement : le coût du recrutement lui-même, le coût complet du poste sur trois ans, les mois de non-production au démarrage, et une probabilité non nulle de devoir recommencer une fois.

Côté studio : le coût du projet, plus la maintenance annuelle — qui est une fraction du projet initial.

Ce calcul ne donne pas toujours le même gagnant. C'est précisément pour ça qu'il faut le faire au lieu de trancher au réflexe.

Quand recruter est le bon choix

Il faut le dire clairement, parce que c'est vrai plus souvent qu'un prestataire n'aime l'admettre.

Quand vous avez déjà une équipe technique. Un développeur de plus dans une équipe qui existe est immédiatement encadré, relu et intégré. Le coût de dépendance disparaît. C'est le cas le plus favorable, et de loin.

Quand le logiciel est votre produit. Si ce que vous construisez est ce que vous vendez, il doit vous appartenir en compétence autant qu'en propriété. Une équipe interne est la seule réponse durable.

Quand la charge est réellement continue. Une roadmap pleine pour deux ans, ce n'est pas une mission, c'est un poste.

Quand un studio l'est

Quand le besoin est délimité. Sortir un processus d'un tableur, connecter deux systèmes, construire un outil métier : ce sont des projets qui ont un début et une fin, suivis d'une maintenance légère.

Quand vous n'avez pas d'équipe technique. Recruter un développeur isolé dans une entreprise qui n'en a aucun, c'est créer un point de fragilité, pas une capacité.

Quand le délai compte. Six mois de recrutement plus six mois de montée en compétence, ou une première version en quelques semaines : ce n'est pas le même projet.

Quand vous voulez savoir avant de vous engager. C'est notre argument, et il n'a pas d'équivalent côté recrutement : vous ne saurez si le logiciel vous convient qu'en le voyant tourner. Nous commençons donc par un périmètre réduit et un prototype fonctionnel. S'il ne convient pas, il n'est pas facturé. Un recrutement raté, lui, se paie intégralement.

La question qui tranche

Une seule, et elle est simple.

Est-ce que ce logiciel a besoin d'évoluer tous les mois pendant les cinq prochaines années ?

Si oui, vous avez besoin d'une équipe, et l'internaliser finit toujours par être la bonne réponse.

Si non — si vous avez besoin qu'un processus critique cesse de tourner sur des fichiers, puis qu'il soit maintenu correctement — alors vous n'avez pas un problème de recrutement. Vous avez un projet.