« On a besoin d'un logiciel sur mesure. »
On entend ça à presque chaque premier appel. Parfois le client a raison. Parfois il est sur le point de passer six mois et un budget conséquent à construire quelque chose qui existe déjà pour 50 $/mois.
Une partie de notre travail, c'est de connaître la différence — et d'être honnête, même quand l'honnêteté signifie dire à un prospect de ne pas nous engager.
Cet article est le cadre qu'on utilise en interne pour évaluer les décisions build-vs-buy. On le partage parce que si vous vous posez cette question, vous méritez une réponse directe avant de vous engager.
Le réflexe par défaut devrait être d'acheter
Ça peut sembler étrange venant d'une agence qui construit du logiciel sur mesure. Mais la position de départ devrait toujours être : ne construisez pas.
Des outils prêts à l'emploi existent pour presque tout. Gestion de projet, CRM, facturation, RH, inventaire, e-commerce — il y a des produits matures dans chaque catégorie, la plupart meilleurs que ce qu'une agence construira from scratch dans un délai comparable.
La charge de la preuve devrait être sur la construction, pas sur l'achat. Si vous ne pouvez pas clairement expliquer pourquoi un outil existant ne marchera pas, vous ne devriez pas construire.
Quand acheter est le bon choix
Achetez quand le problème que vous résolvez est générique et bien servi par des produits existants. Si vos besoins correspondent à ce qu'un produit fait déjà — même si ce n'est pas parfait — acheter est presque toujours la bonne décision.
Concrètement, achetez quand votre workflow est standard pour votre industrie et ne nécessite pas de logique unique, quand les limitations de l'outil sont cosmétiques plutôt que structurelles, quand l'éditeur a un historique de fiabilité et de développement actif, et quand vous auriez besoin de moins de 20 % de personnalisation pour que ça fonctionne.
Un CRM qui ne correspond pas exactement à vos labels de champs ? Achetez-le et adaptez votre processus. Un outil de facturation qui n'a pas un rapport spécifique ? Achetez-le et exportez dans un tableur. Ce sont des inconvénients, pas des raisons de construire.
Le coût de construction inclut non seulement le développement, mais aussi la maintenance continue, l'hébergement, les mises à jour de sécurité, les corrections de bugs, et les demandes d'évolution — pour toujours. Un abonnement SaaS gère tout ça pour vous.
Quand construire est le bon choix
Construisez quand votre avantage concurrentiel dépend d'un logiciel qui n'existe pas, ou quand les outils existants vous forcent à casser votre workflow principal.
Voici les patterns qu'on a observés où construire était la bonne décision :
Le processus est votre produit. Si votre entreprise fonctionne sur un workflow réellement unique — pas « unique » dans le sens « on aime faire différemment », mais unique dans le sens « c'est comme ça qu'on crée de la valeur » — alors forcer ça dans un outil générique compromet ce qui vous rend compétitif.
Vous avez dépassé l'outil. Vous avez commencé avec une solution prête à l'emploi, ça a marché un temps, et maintenant vous butez. Les intégrations sont fragiles. Les contournements se multiplient. Votre équipe passe plus de temps à combattre l'outil qu'à l'utiliser. C'est le déclencheur le plus courant et le plus légitime pour construire.
La donnée est l'actif. Quand vous avez besoin d'un contrôle total sur comment les données sont stockées, traitées et connectées — pour la conformité, pour l'analytique, ou parce que les relations entre données sont réellement complexes — les outils prêts à l'emploi deviennent un risque plutôt qu'un atout.
L'intégration est le besoin central. Vous n'avez pas besoin « d'un CRM » ou « d'un ERP » — vous avez besoin d'un système qui connecte cinq outils existants en un workflow cohérent. Aucun produit unique ne fait ça parce que c'est spécifique à votre stack.
La zone grise : là où la plupart des mauvaises décisions se prennent
La plupart des erreurs build-vs-buy ne se produisent pas aux extrêmes. Personne ne construit un client email custom. Personne n'achète un outil générique quand il a besoin d'une plateforme de trading temps réel.
Les erreurs arrivent au milieu. La zone grise ressemble à ça :
« L'outil fait 80 % de ce qu'on veut, mais les 20 % restants sont vraiment importants. » C'est la phrase la plus dangereuse en achat de logiciel. Parfois ces 20 % justifient réellement de construire. Plus souvent, c'est une préférence déguisée en exigence. La question à poser : si l'outil faisait ces 20 % mal, est-ce que ça nuirait réellement à votre business, ou est-ce que ça agacerait juste votre équipe ?
« On veut être propriétaire de la PI. » La propriété est une préoccupation valide, mais ce n'est pas automatiquement une raison de construire. Si l'outil que vous construiriez ne fait pas partie de votre avantage concurrentiel, posséder le code n'ajoute pas de valeur — ça ajoute du coût.
« On veut éviter le vendor lock-in. » Aussi valide, mais construire du sur-mesure crée un autre type de dépendance : la dépendance envers l'agence ou l'équipe qui l'a construit. Une dépendance vous coûte un abonnement. L'autre vous coûte de la maintenance.
Si vous évaluez spécifiquement des systèmes ERP et hésitez entre Odoo et du sur-mesure, on a écrit un détail complet des trois voies ERP — Odoo standard, Odoo personnalisé, et sur mesure.
Comment on évalue ça avec les clients
Quand un prospect vient nous voir avec une demande de développement, on passe par une checklist simple avant d'accepter de cadrer quoi que ce soit :
Qu'est-ce qui existe aujourd'hui ? On cherche ce qui est disponible. S'il y a un produit qui couvre 80 %+ du besoin, on recommande au client de l'essayer d'abord. S'il l'a déjà essayé et atteint de vraies limites, on avance.
Quel est le vrai différenciateur ? On demande au client de décrire, en une phrase, ce que son logiciel doit faire que rien sur le marché ne fait. S'il ne peut pas, c'est un signal.
Quel est le comparatif de coût sur 3 ans ? On estime le coût total de construction et de maintenance de la solution sur mesure sur 3 ans — incluant le temps de développement et la maintenance continue. Puis on le compare au coût d'abonnement d'une alternative existante sur la même période. Les chiffres surprennent souvent.
Êtes-vous prêt à le maintenir ? Un logiciel sur mesure n'est pas un achat unique. Il a besoin d'hébergement, de mises à jour, de patchs de sécurité, et de développement continu à mesure que votre business évolue. Si le client n'a pas de plan pour ça — en interne ou via un contrat de maintenance — on le signale comme un risque.
On a déjà dissuadé des clients de construire
Ça arrive. Un prospect vient prêt à commander une plateforme complète, et on lui dit de commencer avec Notion, ou Odoo, ou un Shopify bien configuré. On a recommandé des solutions existantes qui ont fait économiser aux clients des mois et des budgets significatifs.
On préfère donner un conseil honnête et gagner la confiance que de prendre un projet qui ne devrait pas exister. Les clients qu'on dissuade de construire aujourd'hui reviennent souvent avec un vrai besoin de développement plus tard — parce qu'ils se souviennent de l'agence qui n'a pas essayé de leur vendre quelque chose dont ils n'avaient pas besoin.
Ce que ça signifie pour vous
Si vous hésitez entre construire et acheter en ce moment, commencez ici :
Pouvez-vous décrire, en une phrase, ce que votre logiciel sur mesure doit faire qu'aucun produit existant ne fait ? Si oui, vous avez peut-être un cas de construction. Si vous avez du mal à le formuler, essayez un outil existant d'abord.
Si vous décidez de construire, les prochaines questions sont faut-il commencer par un MVP ou un produit complet, comment écrire le brief, et quoi demander à l'agence avant de signer. On a écrit sur comment on livre les projets quand construire est la bonne décision et sur pourquoi on a choisi notre stack technique. Mais parfois la meilleure décision technique, c'est de ne pas construire du tout.
Pas sûr de devoir construire ou acheter ? On en discute ensemble →