Application interne : développer ou acheter ?

La question tombe dans presque chaque PME qui grandit : faut-il développer un outil métier sur mesure, ou acheter un SaaS du marché ? La plupart des dirigeants la tranchent par réflexe. Les uns achètent tout, par peur de « réinventer la roue ». Les autres codent tout, par méfiance envers les abonnements. Les deux ont tort la moitié du temps, parce que la bonne réponse ne dépend pas d’un principe, elle dépend de votre cas.

Ce guide pose le calcul honnête. Quand un SaaS suffit, et c’est souvent le cas. Quand le sur mesure gagne vraiment. Ce que l’IA change au coût du développement en 2026. Et une méthode en quatre questions pour décider sans vous mentir. L’objectif n’est pas de vendre du développement, c’est de vous éviter de payer deux fois : une licence qui ne colle pas, puis la refonte pour en sortir.

Le vrai coût n’est jamais le prix affiché

L’erreur de départ est presque toujours la même : comparer le prix d’entrée. Un SaaS à quelques dizaines d’euros par mois paraît imbattable face à un développement chiffré en milliers d’euros. Mais le prix d’entrée n’est pas le coût. Le coût, c’est le total sur trois ans, ce que les analystes appellent le coût total de possession.

Un SaaS facture par utilisateur, chaque mois, indéfiniment. À trois personnes, c’est indolore. À trente, la ligne devient un poste de dépense à part entière. Ajoutez les modules premium qu’on active un par un, les connecteurs payants, la migration le jour où vous changez d’outil, et le calcul se déplace. Un développement sur mesure fait l’inverse : lourd à poser, léger à porter. Vous payez une fois le socle, puis vous ne payez que ce que vous ajoutez.

La bonne comparaison n’est donc pas « combien coûte le premier mois », c’est « combien j’aurai payé au bout de trois ans, et que me reste-t-il à la fin ». À la fin d’un abonnement, il ne vous reste rien. À la fin d’un développement, il vous reste un actif.

Quand un SaaS du marché suffit, et c’est souvent le cas

Soyons clairs : dans la majorité des besoins standards, acheter est le bon choix, et un bon prestataire vous le dira. Un SaaS mûr, c’est des années de développement mutualisées entre des milliers de clients, une équipe qui le maintient, des mises à jour de sécurité automatiques et un support. Vous n’avez aucune raison de recoder ça.

Le SaaS gagne dès que votre besoin est commun et bien couvert. La comptabilité, la paie, la signature électronique, la messagerie, la visio, le stockage de fichiers : ces domaines sont matures, normés, et votre façon de les faire n’a rien de différenciant. Payer une licence y est plus sûr et moins cher que de tout rebâtir. Le développement sur mesure sur un besoin déjà résolu par le marché est du gaspillage, pas de l’ambition.

La règle tient en une phrase. Si le SaaS couvre votre besoin sans que votre process se torde pour entrer dans ses cases, achetez. Le sur mesure ne se justifie que là où le marché vous laisse un vrai manque.

Quand le sur mesure gagne vraiment

Trois signaux, souvent combinés, font basculer le calcul vers le développement. Aucun n’est une question de goût, chacun est mesurable.

Votre process est un avantage concurrentiel. Si votre façon de traiter une commande, de router un dossier ou de suivre une production est ce qui vous distingue, un SaaS générique vous force à l’aplatir dans les cases d’un éditeur. Vous perdez précisément ce qui vous rend meilleur. Un outil sur mesure porte votre process réel au lieu de le contraindre. C’est là que le sur mesure ne rattrape pas le marché, il le dépasse.

Le coût par siège explose à votre volume. Un abonnement raisonnable à dix utilisateurs peut devenir absurde à cent. Quand la licence annuelle dépasse ce que coûterait de construire et maintenir l’outil, le calcul est fait. Le point de bascule arrive plus vite qu’on ne le croit, surtout quand vous n’utilisez qu’une fraction des fonctions facturées.

Vos données sont éclatées. Le symptôme le plus courant : la même information vit dans un tableur, un CRM, un logiciel de facturation et trois boîtes mail, et personne ne sait laquelle fait foi. Aucun SaaS vertical ne réconcilie ça, parce qu’aucun n’a été pensé pour votre carte à vous. Un outil interne qui se branche à l’existant via API ou MCP devient la source unique qui manquait. C’est souvent le vrai déclencheur, avant même le coût.

Si vous reconnaissez un de ces trois signaux, le sur mesure n’est plus un luxe, c’est le calcul rationnel. Notre page applications internes pour PME détaille les briques concrètes que ça recouvre.

Ce que l’IA change au coût du sur mesure en 2026

Pendant vingt ans, l’argument massue contre le développement tenait en trois mots : trop long, trop cher. C’est cet argument que l’IA fait vaciller.

L’IA de développement accélère l’écriture du code, la génération des tests et l’itération. Un socle qui demandait des mois se pose désormais en semaines. Le coût d’entrée d’un outil sur mesure se rapproche de celui d’un SaaS lourdement configuré, sans en avoir les limites. Le point de bascule du « quand le sur mesure gagne » se déplace donc vers le bas : des besoins qui, hier, ne justifiaient pas un développement le justifient aujourd’hui.

Une précision honnête, parce qu’elle compte. L’IA accélère la fabrication, pas les décisions. Elle n’écrit pas votre architecture à votre place, ne connaît pas votre métier, et ne remplace pas les tests ni les garde-fous sur les accès et les données. Un outil codé vite par un intervenant peu rigoureux, avec ou sans IA, produit une dette aussi lourde qu’un tableur monstrueux. La vitesse ne dispense pas de la rigueur, elle la rend juste plus accessible. Nous creusons cette nuance entre outillage et jugement dans notre comparatif agent IA contre automatisation classique.

La méthode de décision en 4 questions

Plutôt qu’un principe, posez-vous ces quatre questions dans l’ordre. Elles tranchent la plupart des cas sans débat idéologique.

1. Le besoin est-il standard ou différenciant ? S’il est standard et bien couvert par le marché, achetez. S’il porte ce qui vous rend unique, penchez vers le sur mesure. C’est la question qui pèse le plus lourd.

2. Combien ça coûte sur trois ans, pas sur un mois ? Faites le total : licences par utilisateur multipliées par vos effectifs réels, sur trente-six mois, modules et connecteurs inclus. Comparez au coût de construction et de maintenance d’un outil possédé. Le gagnant apparaît souvent nettement.

3. Vos données doivent-elles se réconcilier ? Si l’information vit éparpillée et qu’aucun SaaS ne fait office de source unique, un outil interne branché à l’existant reprend l’avantage. Si un SaaS central suffit déjà, ne bougez pas.

4. Que restera-t-il à la fin ? Après trois ans d’abonnement, vous ne possédez rien. Après un développement livré et documenté, vous possédez un actif transférable. Si la propriété du code et l’absence de captivité comptent pour vous, le sur mesure l’emporte à égalité de coût.

Une réponse tranche rarement seule. Mais si trois des quatre pointent dans la même direction, vous avez votre décision, et elle est fondée sur votre activité, pas sur une mode.

Les deux pièges à éviter

Il y a une troisième voie, celle que personne ne choisit mais où beaucoup finissent : le bricolage. Elle a deux visages, et les deux coûtent cher.

L’outil Frankenstein de tableurs. À force de coller des feuilles, des macros et des dépendances entre fichiers, une PME finit par piloter son métier sur un assemblage que personne ne comprend entièrement, sans rôles, sans trace, sans sauvegarde fiable. Une cellule effacée casse un calcul critique et personne ne sait qui a changé quoi. Ce n’est ni acheter ni construire, c’est accumuler de la dette en silence. C’est exactement ce qu’un back-office remis d’aplomb corrige, comme sur la refonte de Balzeo, où le coût de maintenance a fondu une fois l’assemblage remplacé par un socle propre.

Le SaaS jamais adopté. L’autre piège est plus discret : acheter un outil puissant que personne n’utilise vraiment. Trop de fonctions, trop loin des habitudes de l’équipe, une licence payée pour dix pour cent des cas d’usage. Le SaaS n’est pas en cause, l’ajustement l’est. Un outil, acheté ou construit, ne crée de valeur que s’il épouse la façon réelle de travailler. Un développement sur mesure a ici un avantage structurel : il part de votre process, pas de celui d’un éditeur. C’est ce qui a permis aux Carnets de Montpellier de faire tourner abonnements et espace membre dans un outil taillé pour eux, plutôt que dans une plateforme générique mal ajustée.

Les deux pièges partagent une racine : on a évité de décider. Le bricolage est un non-choix qui se paie, et le SaaS mal adopté est un achat sans cadrage. La décision build vs buy, prise honnêtement, vous en sort.

Notre position, sans théâtre

Waimia développe des outils métier sur mesure pour les PME, et pourtant nous recommandons régulièrement d’acheter un SaaS quand il couvre le besoin. Ça peut sembler contre-intuitif de la part d’un studio de développement. C’est simplement honnête : vous conseiller un sur mesure inutile, c’est vous vendre de la dette.

Notre travail commence par le cadrage, pas par le code. On regarde votre process, vos volumes, l’état de vos données, et on vous dit franchement quand le marché fait mieux et moins cher. Quand le sur mesure s’impose, on construit une première version utile vite, sur le périmètre qui fait le plus mal, avec de vrais garde-fous : accès par rôle, journal, sauvegardes, cas limites testés. Et le code est à vous, livré et documenté. Quand l’outil interne devient une brique d’un ensemble plus large, il rejoint un système opérationnel et IA qui relie vos automatisations et vos agents IA. Ce raisonnement build vs buy est le cousin, côté outillage interne, de celui que nous tenons sur la technologie web dans Webflow contre WordPress contre site codé avec l’IA.

Si vous hésitez sur votre propre cas, ne tranchez pas seul dans le vide. Notre diagnostic de maturité IA situe où vous en êtes, et un échange court suffit souvent à savoir s’il faut acheter, construire, ou d’abord réconcilier l’existant. Réservez un diagnostic → : on vous dira honnêtement de quel côté penche votre calcul.