Software house: quand engager (et quand ne pas) — le guide du fondateur non technique

La première fois que j’ai parlé à un fondateur qui s’était fait avoir par une software house, il m’a montré un dépôt de onze mille fichiers, sans README, sans tests, et trois commits intitulés final-final.zip. L’entreprise qui avait livré tout ça ne répondait plus aux messages depuis quatre mois. Il avait payé R$ 320 000. Il avait un système qui marchait. Presque. Et plus personne autour de lui n’était capable d’y toucher.

La question qu’il m’a posée, celle qui revient sous une forme ou une autre dans presque chaque première réunion avec un fondateur non technique, était la suivante: “ça vaut le coup d’engager une software house, ou j’aurais dû faire autrement?”

Oui, dans la plupart des cas. Mais la question est mal posée. Une software house n’est pas un choix opposé au freelance ou à l’équipe interne. C’est l’une des quatre vraies options qu’un fondateur a pour construire un produit, et chacune fait sens à un moment précis. L’erreur qui a coûté R$ 320 000 au fondateur ci-dessus n’a pas été de choisir une software house. Ça a été de choisir cette software house pour les mauvaises raisons.

Ce guide explique comment décider, et comment décider bien.

Ce qu’est une software house, concrètement

Une software house est une entreprise qui conçoit et construit du logiciel sur mesure pour d’autres entreprises. La version courte: une équipe pluridisciplinaire (produit, design, ingénierie) qui livre un système en production, de la conception au déploiement, sans que le client ait à monter une équipe tech interne.

Dans la pratique, ce qui distingue une software house des autres façons d’embaucher de l’ingénierie, c’est la portée du livrable. Une software house livre le produit. Un freelance livre des heures. Une équipe interne livre une équipe. Les trois coûtent de l’argent différemment, demandent une gestion différente et produisent des résultats différents.

Cette idée de “livrer le produit” n’est pas anodine. Elle veut dire que la software house est responsable de l’ensemble: spec, choix d’architecture, code, QA, infrastructure, et la documentation qui permet à quelqu’un d’autre de continuer le travail. Quand la livraison est bonne, le fondateur termine le projet avec un système qui tourne, un dépôt lisible et la possibilité réelle d’internaliser l’équipe ensuite. Quand elle est mauvaise, il termine avec onze mille fichiers sans propriétaire.

Les quatre vraies options (et ce que chacune fait bien)

Avant de décider d’engager une software house, il faut poser sur la table les quatre options réelles que tu as. Chacune résout un ensemble de problèmes et en crée un autre.

No-code. Bubble, Glide, Softr, Retool. Utile pour valider une idée avant de payer de la vraie ingénierie. Casse à la première personnalisation que la roadmap du fournisseur n’avait pas prévue. Il y a un plafond. La majorité des fondateurs y restent six à douze mois de plus qu’ils ne le devraient.

Freelance ou dev solo. Pas cher à l’heure, cher au cumul. Excellent pour une petite tranche bien définie (un connecteur, un script, une feature isolée). Mauvais pour construire un produit complet: pas de revue de code, pas de redondance, personne avec qui débattre des arbitrages d’architecture. Si le dev part, le système devient orphelin.

Équipe interne (CTO + deux ou trois ingénieurs). Le meilleur chemin quand le logiciel est le métier et que l’entreprise a la maturité pour gérer de l’ingénierie. Cher à monter, lent à atteindre son rythme, difficile à manager si tu ne viens pas du domaine. Si l’entreprise n’a pas atteint le stade où le logiciel est un avantage compétitif réel, c’est trop tôt.

Software house. Livre le produit et la documentation. Démarrage rapide (semaines, pas mois). Cher à l’heure, mais le coût total est en général inférieur à celui d’une équipe interne équivalente jusqu’à la Série A, parce que tu ne paies que la bande passante que tu utilises. Le risque, c’est de dépendre d’un fournisseur pour un actif central; la façon de le contenir tient au contrat et à qui tu engages, et chacun de ces sujets a sa propre section plus loin.

La règle pratique qui en découle est simple: plus le système est central pour l’entreprise et plus il va changer dans les douze prochains mois, plus la balance penche vers une équipe interne. Plus le système est complémentaire et plus le fondateur a besoin de garder son focus ailleurs (ventes, fundraising, régulation), plus elle penche vers une software house. Le freelance ne gagne que sur les petits morceaux. Le no-code ne gagne qu’en validation.

Le cadre des quatre questions

J’utilise quatre questions avec n’importe quel fondateur avant de lui recommander d’engager une software house, et avant d’accepter de travailler avec un nouveau client. Si trois des quatre réponses vont dans le même sens, la décision est facile. Quand elles se divisent, il vaut mieux discuter encore avant de signer quoi que ce soit.

1. À quel point la spec est-elle claire?

Ce n’est pas “as-tu un document de spécifications”. C’est “es-tu capable d’expliquer, en deux phrases, quel problème tu résous et pour qui”. Une software house est bonne pour traduire une idée claire en système. Elle n’est ni bonne (ni bon marché) pour t’aider à découvrir quelle est l’idée.

Si la réponse est “je suis encore en train de valider le problème”, arrête. Fais d’abord la phase de découverte, avec toi-même et avec les premiers clients. Achète un abonnement Bubble s’il le faut. Reviens à la software house quand la spec est solide. Chaque heure qu’une software house passe sur la découverte produit te coûte cinq fois ce que la même heure coûterait passée sur le code.

2. À quel point le système est-il central pour l’entreprise?

Il y a des systèmes qui sont le produit (toute la fintech tourne sur le core bancaire) et des systèmes qui débloquent les opérations (le tableau de bord interne qui a libéré trois personnes de l’équipe ops). Les deux méritent du logiciel bien fait. Mais le type de relation contractuelle et le type de transition que tu veux à la fin sont différents.

Pour les systèmes centraux, planifie l’internalisation de l’équipe dès le premier jour. La software house idéale est celle qui t’aide à recruter tes premiers ingénieurs, transfère le contexte et s’efface quand tu n’as plus besoin d’elle. Pour les systèmes internes, une software house peut être l’équipe permanente. Il n’y a rien de mal à garder un partenaire de long terme pour s’occuper des outils internes; il faut juste que ce soit explicitement convenu.

3. À quelle étape es-tu et quelle runway te reste-t-il?

Pre-seed et seed avec une runway courte: la vitesse compte avant tout. Une software house livre vite parce que l’équipe est déjà constituée. Passer trois mois à recruter un CTO avant de commencer à construire, c’est trois mois que tu ne récupères pas.

À partir de la Série A, avec un PMF clair et une roadmap longue, l’équation change. Une équipe interne devient moins chère au cumul, génère un actif (un talent qui grandit avec l’entreprise) et crée de la continuité. C’est le point de transition naturel: software house pour décoller, équipe interne pour passer à l’échelle.

4. Qui est propriétaire du code dans dix-huit mois?

C’est la question qui sépare les software houses sérieuses des autres. Pose-la explicitement, avant de signer: le dépôt est sur le GitHub de mon entreprise dès le premier jour. La documentation m’appartient. Quand j’engagerai mes premiers ingénieurs, ton équipe s’asseoira avec eux, transférera le contexte et sortira sans casse.

Si la software house esquive ou conditionne sa sortie à une licence, à des royalties ou à un contrat de support obligatoire, fuis. Les contrats honnêtes sont brefs sur ce point. Le code est à toi. Il l’a toujours été.

Comment évaluer une software house sans simuler une compétence technique

C’est là que la plupart des fondateurs non techniques bloquent. Tu n’as pas à évaluer le stack qu’ils proposent. Tu dois évaluer comment ils pensent.

Demande le post-mortem du projet qui s’est le plus mal passé. Une software house sérieuse en a un. Une software house qui dit “on n’a jamais eu de problème” ment ou est trop jeune pour avoir un historique. Ce qui compte, ce n’est pas l’erreur; c’est le niveau de détail et l’autocritique dans la réponse.

Demande des références et appelle-les caméra coupée. Les anciens clients qui ont terminé le projet il y a au moins six mois sont le meilleur échantillon. Pose des questions concrètes: le budget a-t-il été tenu? Qui maintenait le système quand l’équipe a quitté? Tu les rappellerais? Quand une référence hésite, tu entends la vérité.

Demande à rencontrer ceux qui vont travailler sur ton projet, pas seulement le sales. Une software house sérieuse te laisse parler avec le tech lead qui va piloter l’équipe. Une mauvaise garde un commercial impeccable en façade et cache l’équipe qui livre.

Demande une proposition au périmètre, pas à l’heure. “On va facturer 1 200 heures à R$ 250” n’est pas une proposition. C’est un chèque en blanc. “On va livrer le module X pour R$ Y, en Z semaines, avec des critères d’acceptation écrits”, c’en est une. Une software house qui ne vend que des heures te dit qu’elle n’a pas confiance dans son propre périmètre.

Regarde le portfolio avec scepticisme. Joli sur Behance ne veut pas dire bon en production. Demande lequel de ces projets tourne encore, lequel a été abandonné, lequel le client a repris pour le confier à un autre prestataire. L’histoire après le lancement est ce qui compte.

Combien coûte une software house

Il existe une fourchette raisonnable et il existe des extrêmes dangereux. Les moyennes ci-dessous correspondent à des projets de produit numérique de complexité modérée, avec une petite équipe (2 à 5 personnes affectées), à São Paulo, Rio, ou dans d’autres capitales avec un marché tech mature.

Taux horaire moyen sur le marché brésilien (2026): R$ 180 à R$ 350 de l’heure pour des équipes seniors, R$ 100 à R$ 180 pour des équipes mixtes avec plus de juniors. En dessous de R$ 100, méfiance. Au-dessus de R$ 400, tu paies une marque, et ça peut valoir le coup ou pas.

Projet de MVP (3 à 4 mois): R$ 250 000 à R$ 600 000 est la fourchette dans laquelle tombent les projets honnêtes. En dessous, soit le périmètre est minuscule, soit quelqu’un coupe les coins. Au-dessus, soit la complexité est réelle (régulation, intégrations lourdes, ML appliqué), soit tu paies du surcoût.

Squad alloué au mois (2 à 3 personnes, en continu): R$ 80 000 à R$ 180 000 par mois, selon la séniorité.

Compare avec l’équipe interne équivalente: un CTO confirmé et deux ingénieurs seniors à São Paulo, charges, outils et équipement compris, coûtent entre R$ 90 000 et R$ 130 000 par mois, et il leur faut trois à six mois pour atteindre la cadence de livraison. Une software house coûte plus cher à l’heure mais commence à livrer dès la troisième semaine.

Ne fais pas ce choix sur tableur. Fais-le sur la runway. Combien de temps avant d’avoir besoin d’un produit qui tourne, et quelle part de ta bande passante tu veux brûler à manager des gens dans cet intervalle?

La conversation contractuelle

Avant de signer, exige explicitement:

• La propriété du code. Le dépôt appartient à ton entreprise, sur le GitHub ou GitLab de ton entreprise, dès le premier commit. Pas de licence, pas de clause limitant l’usage futur, pas de dépendance à la plateforme propriétaire du prestataire.
• Une clause de sortie sans casse. Que se passe-t-il quand l’une des parties décide d’arrêter? Préavis, transition assistée, transfert de connaissances documenté. Tout par écrit.
• Un SLA de communication, pas seulement d’uptime. En combien de temps répondent-ils? Qui est ton interlocuteur? Que se passe-t-il quand le tech lead est en vacances?
• Des critères d’acceptation par livrable. Ce qui compte comme “fait” pour chaque module. Concret, mesurable.
• Un plafond au scope creep. Les changements de périmètre génèrent un avenant, avec un délai et un coût recalculés. Pas une boule de neige.

C’est sur ce point que la plupart des relations tournent mal, et elles tournent mal pour quelque chose de basique: personne n’a écrit comment se ferait la sortie. Signe avec une sortie claire.

Signaux d’alerte en cours de projet

Certaines relations avec une software house commencent bien et tournent mal. Les signaux apparaissent avant la livraison finale.

La démo hebdomadaire devient mensuelle. Une software house sérieuse montre du travail toutes les semaines. Quand le rythme des démos baisse, c’est que le rythme de livraison a baissé, ou qu’il y a quelque chose que l’équipe ne veut pas montrer.

Le tech lead change sans prévenir. Les gens partent, c’est normal. Ce qui n’est pas normal, c’est de découvrir trois sprints plus tard que la personne qui pilote ton projet n’est plus celle que tu as interviewée. Une software house solide communique immédiatement les changements de personnes clés.

Les changements de périmètre deviennent tabous. Tu modifies quelque chose, ils acceptent sans renégocier le délai. Cinq changements plus tard, la livraison a trois mois de retard et personne ne sait pourquoi. Un changement de périmètre devrait générer une friction saine; quand ce n’est pas le cas, quelqu’un accumule de la dette invisible.

Les commits deviennent génériques. “fix bug”, “ajustements”, “WIP” comme message d’une journée entière de travail. C’est l’équivalent code de “je t’expliquerai plus tard”.

Quand deux de ces signaux apparaissent ensemble, demande une discussion franche, avec un ordre du jour écrit, sans le sales dans la pièce. La majorité des relations qui tournent peuvent être rattrapées si la conversation a lieu au troisième mois. Presque aucune ne peut l’être au huitième.

Le choix n’est pas entre prestataires; il est entre futurs

Toute embauche de software house est en réalité un pari sur le type d’entreprise que tu veux être dans dix-huit mois. Une software house bon marché et désengagée te livre un système qui tient jusqu’au prochain tour et coince ensuite. Une sérieuse te livre un système, un manuel, et une transition propre vers l’équipe que tu finiras par recruter.

L’écart de prix entre les deux est plus petit qu’il n’y paraît. L’écart de destination, c’est tout le reste de l’entreprise.

Si la décision est difficile, reviens aux quatre questions. À quel point la spec est claire, à quel point le système est central, à quelle étape tu es, et qui est propriétaire du code dans dix-huit mois. En général, trois des quatre réponses pointent dans la même direction. Quand elles le font, vas-y. Quand elles ne le font pas, attends une semaine et parle à un client de plus de la software house avant de signer.

La bonne décision n’est pas la moins chère, ni la plus sophistiquée. C’est celle qui te laisse dormir en sachant qui construit quoi et pourquoi.