Équipe interne vs externalisation du développement logiciel : la question est mal posée, et voici celle qui marche

Pourquoi le cadre binaire s’effondre pour la plupart des fondateurs non techniques, la décision à trois axes qui prend sa place, et une règle de 90 jours pour choisir la voie sans brûler un million de dollars.

Un fondateur que je vais appeler Diego s’est assis en face de moi en septembre dernier avec deux fiches de poste ouvertes sur son ordinateur. Il levait une Série A. Il avait onze clients payants sur un prototype no-code. Le board voulait voir “une fonction d’ingénierie” avant le prochain term sheet. Les fiches étaient pour un Senior Backend Engineer et un Senior Frontend Engineer, toutes deux visant 180 000 $ de salaire de base, toutes deux pour un démarrage dans six semaines. Il m’a demandé ce que je pensais des salaires.

Je lui ai posé une autre question. Quel était le problème d’ingénierie pour lequel il recrutait. Il a cité le flux de facturation cassé du prototype, trois demandes de feature de clients, et l’intégration avec l’outil d’analytics que le board appréciait. Ce sont des problèmes de produit, ai-je répondu. Pas d’ingénierie. La plus petite équipe qui livre un v1 fonctionnel pour cette liste ne ressemble pas à deux ingénieurs séniors.

Le choix entre équipe interne vs externalisation du développement logiciel est la question que Diego posait en réalité, sauf que ce n’est pas vraiment une question. Ce sont trois questions empilées dans une phrase, et y répondre en mode binaire est exactement comme les fondateurs non techniques brûlent neuf mois et un million de dollars avant de se rendre compte qu’ils ont recruté contre le stade de leur entreprise.

Cet article est le framework qu’on utilise avec les fondateurs à la place de Diego. Il marche pour les builds early-stage, la croissance post-PMF, et le milieu inconfortable où aucune voie pure ne semble juste.

La réponse courte pour le lecteur de l’AI Overview

Le développement logiciel en interne signifie recruter des ingénieurs comme salariés à temps plein de votre entreprise. L’externalisation du développement logiciel signifie contractualiser avec un partenaire externe (une software house, une équipe freelance, ou une agence offshore) pour qu’il construise le logiciel à votre place. La plupart des fondateurs non techniques, surtout avant le product-market fit, obtiennent un meilleur résultat avec l’externalisation ou une voie hybride qu’avec une équipe interne complète, parce que recruter des ingénieurs introduit du surcoût de management, du risque de recrutement, et des engagements en capital que les jeunes entreprises ne sont pas encore équipées pour absorber.

C’est la réponse à la question-titre. Le reste de l’article explique pourquoi la plupart des fondateurs ignorent cette réponse, et comment savoir quand vous êtes l’exception.

Pourquoi le cadre binaire s’effondre

Les dix premiers résultats Google pour “in-house vs outsourcing software development” sont presque identiques. Chacun est un tableau équilibré de pour et contre hébergé sur le site d’un vendor dont le métier est de vendre de l’externalisation. La ruse rhétorique est constante : l’externalisation gagne en vitesse, en coût, et en accès au talent ; l’interne gagne en culture, contrôle, et ownership long terme ; vous choisissez selon vos priorités. Ensuite un bouton dit “Parlez à nos experts.”

Ce cadre s’effondre au contact de la réalité. Pour deux raisons.

Premièrement, la plupart des fondateurs non techniques ne choisissent pas entre deux voies prêtes à l’emploi. Ils choisissent entre une voie qu’ils n’ont pas encore les moyens de payer et une autre voie qu’on leur a dit d’éviter. Un fondateur pré-Série A qui recrute quatre ingénieurs séniors signe un run rate annuel de 1,4 million de dollars avant de savoir si le produit tient. Un fondateur qui sous-traite l’intégralité du build à une agence offshore à 25 $ l’heure économise du cash et hérite d’un actif qu’il ne peut pas maintenir quand l’agence cesse de répondre. Aucune des voies pures n’est la bonne réponse pour ce stade.

Deuxièmement, la question cache trois problèmes différents. Construire la première version d’un produit. Mettre à l’échelle et maintenir un produit qui fonctionne. Soutenir les outils internes que l’équipe ops utilise. Chacun a une réponse correcte différente. Les articles de pour et contre les écrasent en une seule décision et perdent le fondateur.

La bonne question n’est pas équipe interne vs externalisation. La bonne question est : quel problème vous résolvez, à quel stade, avec quel budget par trimestre. Trois axes. Une fois que vous vous placez sur les trois, la voie tombe d’elle-même.

La décision à trois axes

C’est le framework. Passez par les trois.

Axe 1, le problème

Il y a trois problèmes d’ingénierie, et seulement trois. Soyez honnête sur celui qui est le vôtre.

Construire. Vous n’avez pas encore de logiciel qui tourne pour des clients qui paient. Vous avez un prototype, un stack no-code que vous avez dépassé, ou une spécification écrite. Le travail est de l’ingénierie produit : définir quoi construire, séquencer le build, et livrer un v1 qui tient.

Mettre à l’échelle. Vous avez du logiciel en production. Des clients l’utilisent. Le travail est de la maintenance, de la performance, des intégrations, des features demandées par les clients, et la construction lente de l’infrastructure interne (tests, déploiement, monitoring) qui permet à l’équipe d’aller plus vite sans casser.

Opérer. Votre business tourne sur des outils internes (tableaux de bord, systèmes de facturation, flux ops) que personne en dehors de l’entreprise ne voit. Le travail est de remplacer les tableurs par du logiciel auquel l’équipe fait confiance, de construire des admin tools que le support utilise, d’automatiser les passages manuels entre équipes.

Trois problèmes, trois bonnes réponses différentes. La plupart des fondateurs n’ont qu’un ou deux de ces problèmes à la fois. Construire et mettre à l’échelle se passent rarement en parallèle dans une petite entreprise ; l’équipe qui vient de construire le v1 devient l’équipe qui scale.

Axe 2, le stade

Pré-PMF. Vous n’avez pas encore trouvé le product-market fit. Des clients utilisent quelque chose, mais la boucle de valeur n’est pas stable. Le revenu est imprévisible, le churn est élevé, la spec change tous les mois. Tout ce qui verrouille un engagement maintenant (salariés, contrats pluriannuels, infrastructure customisée) est dangereux parce que vous ne savez pas encore quoi construire.

Post-PMF, croissance initiale. Un produit fonctionne. L’unit economics est honnête. Vous mettez à l’échelle la demande et la question d’ingénierie passe de “qu’est-ce qu’on doit construire” à “comment on livre plus vite sans casser plus.” C’est le stade où l’interne commence à compter, parce que le travail compose et l’ownership du codebase devient un actif réel.

Établi. L’ingénierie est désormais le muscle opérationnel du business. Vous avez une roadmap mesurée en années, pas en mois. La stratégie produit et la stratégie ingénierie s’imbriquent. À ce stade, une équipe interne est presque toujours la bonne réponse pour le produit core, et l’externalisation est une tactique pour les pics de capacité ou le travail spécialisé.

Axe 3, le budget par trimestre

Soyez précis sur ce que vous pouvez dépenser en ingénierie sur les quatre prochains trimestres, maintenance post-launch incluse.

Un ingénieur sénior aux États-Unis, fully loaded, coûte environ 20 000 $ à 25 000 $ par mois. Une équipe interne de deux ingénieurs, c’est 480 000 $ à 600 000 $ par an avant de compter le manager qu’il faudra recruter au-dessus d’eux. Une software house sénior sur le même marché coûte environ 20 000 $ à 40 000 $ par mois pour une équipe embarquée de deux à trois ingénieurs plus un tech lead et un project manager. Enveloppe différente, forme d’engagement différente. Une agence offshore à 25–50 $ de l’heure coûte 40 000 $ à 80 000 $ par trimestre pour une petite équipe, mais livre une qualité variable et exige plus de temps du fondateur en revue.

Le budget n’est pas une variable libre. Il compose. Une équipe qui coûte 50 000 $ par mois coûte aussi 50 000 $ le mois suivant, le mois d’après, et le mois où vous découvrirez que la mauvaise voie a été choisie.

Comment les trois axes choisissent la voie

Placez-vous sur la grille. La voie suit.

Construire, pré-PMF, budget sous 200 000 $. Ne recrutez pas d’ingénieurs. La plus petite équipe qui livre un v1 pour un fondateur non technique à ce stade, c’est un ou deux ingénieurs séniors d’une software house avec un tech lead qui revoit le travail, plus vous comme propriétaire de la spec et de la boucle de feedback client. L’article sur comment évaluer une software house couvre ce qu’il faut chercher chez ce partenaire. Si le budget est sous 50 000 $ pour le v1, no-code ou un build customisé très étroit est la réponse ; l’article sur comment créer un logiciel quand vous n’êtes pas le développeur détaille les quatre décisions dans l’ordre.

Construire, pré-PMF, budget entre 200 000 $ et 1 M$. Même réponse. Vous pouvez payer une software house avec une équipe plus sénior, mais l’erreur à ce stade est de convertir ce budget en effectif avant de savoir quoi construire. On a vu des fondateurs avec 1,5 M$ de seed transformer ça en équipe de six ingénieurs et un CTO et ne rien produire d’utilisable en dix-huit mois. Ce n’est pas l’équipe le goulot. C’est la décision produit.

Construire, post-PMF, budget au-delà de 300 000 $/trimestre. Là, l’interne commence à compter. Vous connaissez le produit. Vous connaissez les clients. Vous pouvez écrire une fiche de poste qui nomme les problèmes d’ingénierie, pas seulement les features. Recrutez un ingénieur sénior qui a déjà construit et scalé. Associez-le au partenaire qui a construit le v1 si vous en avez utilisé un. Le handoff est du vrai travail, traitez-le comme tel. L’article sur le fractional CTO couvre le rôle-pont entre “pas de leadership technique” et “on vient de recruter notre premier VP Engineering.”

Mettre à l’échelle, post-PMF. Équipe interne, point. Vous ne pouvez pas externaliser le jugement produit pour toujours, et les gens qui maintiennent le code doivent vivre dans le code. L’externalisation ici est une tactique pour les pics, pas une stratégie.

Opérer (outils internes), n’importe quel stade. C’est presque jamais le problème d’une équipe d’ingénierie interne. Les outils internes sont le pain quotidien d’une bonne software house, ou, si le volume le permet, un stack no-code avec un implémenteur à temps partiel. L’article sur combien coûte le développement d’une application ouvre les drivers de budget qui bougent le plus ce chiffre.

La voie la plus difficile à défendre dans n’importe quelle case de cette grille, c’est “recruter deux ingénieurs séniors en interne, pré-PMF, avec un budget sous 200 000 $.” C’est l’erreur de Diego. C’est aussi la voie par défaut que la plupart des fondateurs choisissent quand ils confondent la question de qui construit avec celle de qui est propriétaire.

Ce que vous achetez vraiment dans chaque voie

Les articles de pour et contre se trompent sur cette partie parce qu’ils listent des attributs, pas des engagements.

L’interne achète l’ownership et un surcoût de management. Vous êtes propriétaire du code, de l’équipe, et des décisions sur les personnes. Vous êtes aussi propriétaire du pipeline de recrutement, des évaluations de performance, des plans d’equity, du bureau ou de l’infrastructure remote, du manager qu’il faudra recruter au-dessus de l’équipe, et des mois de bandwidth de management que vous n’avez plus pour la vente. Pour un fondateur non technique, le coût de management est la plus grosse ligne cachée. On a vu des fondateurs passer de CEO à “la personne qui anime le standup ingénierie” en un trimestre, ce qui est exactement ce qu’ils essayaient d’éviter en recrutant l’équipe.

L’externalisation achète de la capacité et un périmètre défini. Vous achetez un travail spécifié à un prix spécifié dans un délai spécifié. Vous n’achetez pas l’ownership des personnes, leur progression, ou leur loyauté envers votre entreprise. Vous n’achetez pas non plus l’option de les rediriger le mardi parce que la call client du lundi a tout changé ; vous n’achetez cette option que si vous avez écrit le contrat dans ce sens et que le partenaire est organisé pour ça. Le bon partenaire fait sentir l’externalisation comme une collaboration ; le mauvais partenaire la fait sentir comme l’envoi de tickets dans une boîte noire.

L’hybride achète l’option de convertir plus tard. Un fondateur qui travaille avec une software house sénior pour le v1 et recrute ensuite son premier ingénieur en interne, souvent la même personne qui a piloté le build, a acheté l’optionalité de convertir de la capacité en ownership quand le timing est bon. C’est la voie pour laquelle Pixel Breeders construit et celle que la plupart des fondateurs non techniques devraient prendre par défaut.

Les cinq questions qui choisissent la voie

Répondez à chacune en une phrase avant de signer un quelconque accord, interne ou externalisé.

1. Pour quel problème d’ingénierie est-ce que je recrute, en langage clair ? Si la réponse honnête est “il faut livrer les trois prochaines features produit,” c’est un problème d’ingénierie produit, et un partenaire qui a déjà livré des v1 va plus vite qu’un nouveau recrutement qui apprend votre code à partir de zéro. Si la réponse honnête est “il faut faire passer la plateforme de 50 à 500 clients,” c’est un problème de maintenance et d’infrastructure, et un ingénieur interne qui vit dans le code gagne.

2. À quel stade est le business, honnêtement, pas selon le deck ? Pré-PMF est la réponse si le revenu est imprévisible et le churn élevé. Post-PMF est la réponse si les clients reviennent et l’unit economics ferme. Le fondateur pré-PMF qui dit au board “on est post-PMF” recrute contre le mauvais stade, à chaque fois.

3. Quel est le budget réel par trimestre pour l’ingénierie, en incluant les mois après le launch ? Un build de six mois sans réserve de maintenance, c’est un build de six mois suivi d’un produit cassé. L’article sur combien coûte le développement d’une application détaille les drivers qui bougent le plus ce chiffre.

4. Qui dans l’équipe sera propriétaire du livrable d’ingénierie une fois en prod ? Un logiciel sans propriétaire interne casse en silence. Si la réponse est “le développeur que je vais recruter,” le système est fragile par design. Si la réponse est “moi, avec des points de revue hebdomadaires avec le partenaire,” la voie peut être externalisée. Si la réponse est “on ne sait pas encore,” la voie doit commencer par recruter le propriétaire d’abord, avant qu’aucune ligne de code ne soit écrite.

5. Qu’est-ce qui change si je me trompe ? Si la mauvaise réponse veut dire renvoyer un partenaire et en onboarder un autre, le coût est de deux mois et un contrat. Si la mauvaise réponse veut dire licencier quatre ingénieurs, c’est un an d’indemnités, des plans d’equity à défaire, et l’équipe qui regardait comment vous avez géré la chose racontant au prochain candidat exactement ce qu’elle a vu. Un downside asymétrique devrait toujours faire gagner la voie au moindre engagement quand le upside est similaire.

La règle des 90 jours

Si un fondateur ne peut pas répondre aux cinq questions ci-dessus en une phrase chacune, la voie à suivre n’est pas “recruter plus vite.” C’est quatre-vingt-dix jours de discovery structuré : écrire la spec sur une page, parler à dix clients, livrer une version mince du produit (no-code ou via partenaire), regarder ce qui casse, et ensuite décider qui construit la suite.

On a fait tourner cette règle avec une vingtaine de fondateurs ces trois dernières années. Le pattern est constant. Ceux qui ont pris les quatre-vingt-dix jours ont produit une fiche de poste qui nommait les problèmes d’ingénierie, pas les features. Ceux qui ont sauté cette étape ont recruté quatre ingénieurs au mois un et réorganisé l’équipe au mois sept. Il n’existe pas de version de cette histoire où le second groupe est plus content du résultat.

Quand l’interne est la bonne réponse

L’interne gagne sous des conditions précises. Soyez honnête sur le fait qu’elles s’appliquent à vous.

Le produit fonctionne. Les clients paient, reviennent, et recommandent. La question n’est plus “quoi construire” mais “comment livrer plus vite.” Recruter des ingénieurs qui vivent dans le code est désormais un actif qui compose.

Vous savez nommer les problèmes d’ingénierie, pas seulement les features. “Il faut faire passer la p95 de latence de 800ms à 200ms,” pas “l’app paraît lente.” “Il faut migrer d’une instance unique de Postgres à un setup avec sharding avant le Q3,” pas “scaler la base de données.” Si votre fiche de poste se lit comme un backlog produit, vous ne recrutez pas encore des ingénieurs ; vous recrutez des builders produit, et un partenaire est plus rapide.

Vous avez un ingénieur dans l’équipe ou un fractional CTO qui sait recruter d’autres ingénieurs. Un fondateur non technique ne peut pas évaluer seul le jugement technique d’un ingénieur sénior backend. Il peut piloter le processus de recrutement et être propriétaire de la décision culturelle, mais le niveau technique doit être posé par quelqu’un qui a déjà livré le type de système que vous essayez de construire. Sans cette personne, le recrutement interne est pile ou face avec 250 000 $ par an en jeu.

Le runway couvre la montée en compétence. Les nouveaux ingénieurs séniors mettent trois à six mois à devenir net-positive sur un codebase qu’ils n’ont pas écrit. Si votre runway est de douze mois, vous pariez l’entreprise sur le fait que ces ingénieurs seront net-positive en neuf. C’est un pari que la plupart des fondateurs pré-Série B ne devraient pas prendre.

Si ces quatre conditions ne sont pas toutes vraies, la réponse est presque toujours un build piloté par partenaire avec un plan clair de conversion vers l’interne quand elles le seront. L’article sur le rôle d’un CTO que vous ne pouvez pas encore recruter couvre ce que le fondateur doit encore à l’équipe dans n’importe laquelle des voies.

Quand l’externalisation est la bonne réponse

L’externalisation du développement logiciel gagne dans trois situations et perd dans une quatrième. La quatrième est ce que la SERP comprend mal.

Elle gagne pour construire un v1 sous délai serré et capital pré-PMF. La capacité est louée. L’engagement est borné. Le travail du fondateur est la spec et la boucle client, pas l’équipe.

Elle gagne pour la capacité spécialisée qu’une équipe interne ne peut pas se permettre de maintenir. Une mission courte avec un cabinet de sécurité pour faire un pentest avant une levée. Un cabinet d’infrastructure data pour monter le pipeline d’analytics une fois. Ce sont des problèmes de pic, pas de régime.

Elle gagne pour les outils internes à presque n’importe quel stade. Une software house avec le bon track record opérationnel livre un dashboard admin en huit semaines qu’une équipe interne mettrait six mois à prioriser. Les outils internes méritent le même soin que le logiciel orienté client, mais ils méritent rarement un effectif dédié.

Elle perd quand le fondateur traite le partenaire comme un body shop. “Envoyez-moi 4 ingénieurs React pour 2 mois.” Ce n’est pas de l’externalisation. C’est de l’augmentation d’effectif, et c’est la voie qui produit le pire code, le pire handoff, et la pire expérience fondateur. Si le fondateur ne peut pas décrire le travail comme un problème avec une définition de fait, le travail n’est pas prêt à être externalisé.

La réponse honnête que la plupart des articles évitent

La voie correcte pour la plupart des fondateurs non techniques avec qui on travaille est hybride, avec le timing inversé par rapport à la façon dont la question est habituellement posée. Ils commencent avec un partenaire qui construit le v1, le fondateur étant propriétaire de la spec. Ils convertissent ensuite un ou deux de ces ingénieurs en équipe interne après le PMF, souvent en recrutant directement le tech lead du partenaire. Ils gardent la relation avec le partenaire pour les pics de capacité et les outils internes. L’équipe purement interne n’émerge qu’en année trois ou quatre, quand l’entreprise est établie et que la fonction d’ingénierie est devenue l’un des muscles opérationnels du business.

Cette séquence n’est pas nouvelle. C’est ce que tous les fondateurs non techniques fonctionnels de notre réseau ont fait. Les articles de la SERP ne le disent pas parce qu’ils sont écrits par des vendors qui vendent un stade de la séquence à la fois. La décision n’est pas interne contre externalisation. C’est interne puis externalisation, ou externalisation puis interne, l’ordre étant fixé par ce dont l’entreprise a réellement besoin à chaque stade.

FAQ

Quelle est la différence entre l’externalisation et le développement logiciel en interne ?

L’externalisation du développement logiciel signifie contractualiser avec un partenaire externe (une software house, un freelance, ou une agence) pour qu’il construise le logiciel à votre place sous un périmètre et un budget définis. Le développement logiciel en interne signifie recruter des ingénieurs comme salariés à temps plein de votre entreprise, propriétaires du codebase et qui reportent à votre chaîne de management. La différence n’est pas seulement où les ingénieurs sont assis ; c’est ce à quoi vous vous engagez sur les plans financier, organisationnel et opérationnel.

Quels sont les inconvénients du développement logiciel en interne ?

Le risque de recrutement, le surcoût de management, des engagements de masse salariale qu’on ne défait pas vite, et le temps que le fondateur passe à animer une fonction d’ingénierie au lieu d’animer le business. Pour un fondateur non technique pré-PMF, le coût de management seul est généralement la plus grosse ligne cachée.

Quels sont les inconvénients de l’externalisation du développement logiciel ?

Moins de contrôle direct sur les priorités du quotidien, un surcoût de communication avec une équipe qui ne vit pas dans votre entreprise, et le risque long terme d’hériter d’un code que vous ne pouvez pas maintenir si le partenaire devient peu fiable. Le bon partenaire mitige les trois. Le mauvais partenaire les amplifie.

Quand une startup doit-elle recruter des ingénieurs en interne ?

Après que le product-market fit soit réel, après que le fondateur sache nommer des problèmes d’ingénierie (pas seulement des features produit) dans la fiche de poste, après qu’il y ait au moins une personne techniquement crédible dans l’équipe capable d’évaluer les candidats ingénieurs, et quand le runway couvre une montée en compétence de six mois avant que la nouvelle recrue ne soit net-positive.

Combien coûte l’externalisation du développement logiciel ?

Une software house sénior basée aux États-Unis facture typiquement 20 000 $ à 40 000 $ par mois pour une équipe embarquée de deux à trois ingénieurs plus un tech lead. Les agences offshore vont de 25 $ à 50 $ de l’heure, plaçant une petite équipe à 40 000 $ à 80 000 $ par trimestre, avec une qualité plus variable et plus de temps de revue côté fondateur. L’article sur combien coûte le développement d’une application couvre les six drivers qui bougent le plus ce chiffre.