Développer ou acheter un logiciel : comment trancher

Développer ou acheter un logiciel : la question arrive presque toujours au même moment. Un tableur a grossi, une équipe a doublé, un client demande un suivi qu'on ne sait pas produire. Vous regardez le marché, vous voyez trente éditeurs qui promettent tous de résoudre votre problème, et vous vous demandez si le vôtre est vraiment celui qu'ils décrivent. Cet article ne défend pas une voie contre l'autre. Il vous donne une grille pour trancher, avec les cas où acheter est clairement le bon choix, ceux où construire l'est, et un troisième terme que presque personne ne pose.

Autant l'annoncer tout de suite : nous construisons des applications sur mesure. Et nous disons régulièrement à des dirigeants d'acheter un logiciel du marché. Un constructeur qui répond toujours « construisez » n'est pas un conseiller, c'est un vendeur.

Se situer en trois questions

Avant de comparer des prix, répondez à ces trois questions. Elles suffisent, dans la grande majorité des cas, à orienter la décision.

1. Votre besoin est-il standard, ou spécifique à votre façon de travailler ?

Standard veut dire : n'importe quelle entreprise de votre taille a exactement le même besoin, formulé de la même manière. La paie. La comptabilité. La signature électronique. La facturation électronique. Ces domaines sont normés, souvent par la loi, et vous n'avez aucun intérêt à réinventer une règle que l'État réécrit tous les deux ans.

Spécifique veut dire : votre manière de faire est ce qui vous différencie. Votre méthode de chiffrage, votre logique de planning, votre façon de suivre un dossier client de bout en bout. Là, un outil générique vous demande d'abandonner ce qui marche.

2. Combien de personnes vont s'en servir, et pendant combien de temps ?

Cinq utilisateurs sur un besoin secondaire, ce n'est pas le même calcul que trente personnes qui vivent dedans huit heures par jour. Plus le nombre d'utilisateurs monte, plus l'abonnement pèse et plus le sur-mesure devient rationnel. Nous y revenons avec des chiffres plus bas.

3. Tenez-vous un fichier À CÔTÉ de votre logiciel actuel ?

C'est le signe le plus fiable qui existe. Si vos équipes maintiennent un tableur en parallèle pour compenser ce que l'outil ne sait pas faire, la question est déjà tranchée. Vous payez un abonnement, et vous payez en plus du temps humain pour boucher les trous. Ce tableur, c'est le cahier des charges de votre future application, écrit gratuitement par les gens qui connaissent le métier.

Les cas où acheter gagne, sans discussion

Il faut le dire franchement, sinon rien de ce qui suit n'est crédible.

Le besoin est standard et réglementé. Paie, comptabilité, déclarations sociales, facturation électronique. La réglementation change, et les éditeurs du marché absorbent ce changement pour vous. Construire là-dedans, c'est s'engager à suivre soi-même la loi. Personne ne veut de ce contrat.

Le marché est mûr, avec plusieurs éditeurs sérieux. Quand cinq acteurs installés se disputent le même segment depuis dix ans, les fonctions se sont alignées, les prix se sont tassés et la documentation existe. Vous achetez un produit rodé par des milliers d'utilisateurs avant vous.

Vous êtes moins de dix utilisateurs. À ce volume, un abonnement reste supportable et le sur-mesure a du mal à se rentabiliser, sauf si le besoin est vraiment très particulier.

Rien dans ce processus ne vous distingue. Si vous faites comme tout le monde et que ça vous convient, prenez ce que tout le monde prend. Le sur-mesure a un coût d'attention : il faut décider, arbitrer, tester. Ne dépensez pas cette attention sur un sujet qui ne fait pas votre valeur.

À COMPLÉTER : un cas concret où nous avons recommandé à un prospect d'acheter un logiciel du marché plutôt que de construire (secteur, besoin, outil conseillé). Demander à Marine.

Les cas où construire gagne

Vous tordez votre façon de travailler pour rentrer dans l'outil. Vous avez changé un processus qui marchait, pas parce qu'il était mauvais, mais parce que le logiciel ne savait pas le gérer. Le coût de cette torsion est invisible dans le budget et bien réel dans les journées de vos équipes.

Vous maintenez des fichiers de compensation. Le point vu plus haut. Un tableur de suivi, un second export retravaillé à la main, un document partagé qui contient la vraie information. Chaque compensation est un aveu.

Votre processus est votre avantage concurrentiel. Vous répondez plus vite, vous chiffrez mieux, vous suivez plus finement. Mettre ça dans un outil standard, c'est vous aligner sur vos concurrents qui utilisent le même.

Vos données sont éclatées dans cinq outils qui ne se parlent pas. Les gens passent leur temps à recopier. Vous ne payez plus un logiciel, vous payez de la ressaisie.

Le besoin combine deux ou trois métiers. Aucun éditeur ne couvre l'intersection, donc vous achetez trois abonnements et vous les faites tenir ensemble avec de la bonne volonté.

Si vous voulez comprendre à quoi ressemble concrètement une application construite pour un métier précis, l'article c'est quoi un logiciel métier sur-mesure détaille ce que ça couvre et ce que ça ne couvre pas.

À COMPLÉTER : un cas où un client avait acheté un logiciel du marché, puis a dû construire quand même. Ce qui a déclenché le changement. Demander à Marine.

Le troisième terme : acheter puis brancher

La question « développer ou acheter un logiciel » est mal posée quand elle suppose qu'il faut choisir pour toute l'entreprise. Dans la pratique, la réponse la plus économique est souvent mixte.

Vous gardez le logiciel du marché là où il est imbattable : la comptabilité, la paie, la facturation, la signature. Et vous construisez uniquement la pièce qui manque, celle qui porte votre spécificité, en la faisant communiquer avec l'existant.

Exemple de découpage typique dans une PME :

Ce découpage réduit fortement le périmètre à construire. Vous ne financez pas une refonte de tout votre système : vous financez la moitié qui n'existe nulle part. Et vous cessez de payer trois abonnements pour approcher un besoin qu'un seul outil, taillé pour vous, couvre entièrement.

Comparer les coûts sur cinq ans, pas le prix d'entrée

C'est ici que la plupart des arbitrages dérapent. On compare un abonnement mensuel à un investissement, ce qui n'a aucun sens. Il faut poser le coût total de possession sur la durée de vie réelle de l'outil, soit cinq ans au minimum.

Prenons un abonnement à 45 € par utilisateur et par mois, un tarif courant pour un outil de gestion en 2026, sur une équipe de trente personnes.

81 000 € sur cinq ans, et vous ne possédez rien à la fin. En face, une application métier sur mesure de périmètre raisonnable se situe couramment dans une fourchette de 5 000 à 25 000 €, payés une fois, plus un coût d'hébergement et d'évolution. Le détail de ce que fait varier cette fourchette est dans notre article sur le prix d'un développement logiciel sur mesure.

Attention, ce tableau ne dit pas « construisez toujours ». Il dit trois choses.

1. En dessous de dix utilisateurs, l'abonnement reste souvent le calcul gagnant.
2. Au-delà de vingt ou trente utilisateurs, l'écart devient tel que la question mérite d'être posée sérieusement.
3. Ce qui pèse le plus lourd n'apparaît dans aucun de ces deux chiffres : le temps que vos équipes passent à compenser un outil mal ajusté. Une heure par personne et par jour sur trente personnes, c'est un poste de coût qui dépasse largement les deux colonnes.

Les postes qu'on oublie des deux côtés

Côté achat : les frais de paramétrage initial, la formation, les modules complémentaires facturés à part, les hausses de tarif à chaque renouvellement, le coût de sortie si vous voulez récupérer vos données.

Côté sur mesure : l'hébergement, la maintenance, les évolutions que vous demanderez forcément, et le temps de vos équipes pendant la phase de cadrage. Ce temps n'est pas du gâchis, c'est ce qui fait que l'outil correspond au métier, mais il faut le budgéter.

Ce que vous perdez en construisant

Un article honnête doit poser les contreparties.

Pas de communauté. Personne n'a écrit de tutoriel sur votre application. Pas de forum, pas de vidéo, pas de consultant tiers qui la connaît déjà. La documentation, c'est celle que le constructeur produit.

Pas de mise à jour réglementaire automatique. Si un texte change et que votre application est concernée, quelqu'un doit intervenir. C'est exactement pour cette raison qu'on évite de construire sur la paie ou la comptabilité.

Une dépendance au constructeur si le code n'est pas remis. C'est le point à verrouiller par contrat. Demandez systématiquement : à qui appartient le code, sous quelle forme il est remis, et qui peut reprendre le travail si vous changez de prestataire. Une application dont vous n'avez ni le code ni les accès vous enferme aussi sûrement qu'un éditeur.

Pas de test avant de payer. Un abonnement s'essaie deux semaines. Une application se cadre puis se construit. D'où l'importance de commencer petit, sur un périmètre réduit, plutôt que de lancer un chantier de dix-huit mois.

À l'inverse, la dépendance éditeur existe aussi côté achat, et elle est plus insidieuse. Hausse de tarif unilatérale, fonction retirée d'un plan, roadmap qui part dans une direction qui ne vous concerne pas, rachat de l'éditeur. Vous n'avez aucun levier.

Trois erreurs fréquentes dans cet arbitrage

Écrire un cahier des charges de cent pages avant d'avoir décidé. Le document devient un catalogue de souhaits, aucun outil n'y répond à 100 %, et vous choisissez celui qui coche le plus de cases plutôt que celui qui règle vraiment le problème. Commencez par la question : qu'est-ce qui nous coûte le plus cher aujourd'hui ?

Confondre logiciel de gestion générique et outil pour votre métier. Un progiciel couvre bien un domaine large, de manière moyenne. Si vous cherchez à comprendre où se situe la frontière, l'écart entre progiciel et développement dédié se joue surtout sur le degré d'ajustement au processus.

Croire que le sur-mesure est devenu gratuit. Les méthodes de développement assistées par l'intelligence artificielle ont réellement raccourci les délais et fait baisser le ticket d'entrée. Ce qui n'a pas changé : le temps de cadrage, la compréhension du métier, les arbitrages. Nous détaillons ce basculement dans ce qui change et ce qui ne change pas quand on développe avec l'IA.

Comment décider cette semaine

Une méthode simple, applicable en quelques jours.

1. Listez les fichiers parallèles que vos équipes maintiennent à côté des outils en place. Chaque fichier est un symptôme, notez qui le tient et combien de temps ça prend.
2. Comptez le nombre réel d'utilisateurs par outil, et calculez la facture cumulée sur cinq ans.
3. Séparez vos besoins en deux colonnes : réglementé/standard d'un côté, spécifique à votre méthode de l'autre.
4. Sur la colonne standard, allez voir le marché. Sur la colonne spécifique, testez deux ou trois outils, et si vous devez tordre votre processus pour les faire entrer, arrêtez le test.
5. Chiffrez le périmètre le plus petit possible du côté sur mesure. Pas la refonte globale : la pièce qui débloque le reste.

Le retour sur investissement se mesure rarement sur la licence économisée. Il se mesure sur les heures de ressaisie supprimées, les erreurs évitées, les délais de réponse client raccourcis. Ce sont ces chiffres-là qu'il faut poser sur la table avant de choisir une voie.

Si après cet exercice vous hésitez encore, c'est souvent que la réponse est mixte : achetez ce qui est standard, construisez ce qui vous distingue. Et si un logiciel du marché fait le travail, prenez-le. Nous vous le dirons.

Faire le point avec Magram

Les trois questions du début — votre besoin est-il standard ou spécifique, combien de personnes s'en serviront et pendant combien de temps, tenez-vous un fichier à côté de votre logiciel actuel — se tranchent plus vite à deux qu'en réunion interne. C'est ce que fait le diagnostic Magram : une dizaine de minutes, un ordre de grandeur chiffré, et vos besoins rangés en deux colonnes, celle qui s'achète et celle qui se construit.

Vous repartez avec un avis franc, y compris quand cet avis est « un logiciel du marché suffira ». C'est celui de cet article, appliqué à votre organisation plutôt qu'en général.

Faire le diagnostic

Discutons de votre projetRéponse rapideSans engagement