Quand créer un logiciel sur mesure : un arbre de décision

Créez un logiciel sur mesure quand un processus vous appartient vraiment, qu'aucun outil du commerce ne le couvre sans contournement, et que vous avez l'horizon pour l'utiliser pendant des années. Achetez quand un outil standard convient déjà, ou quand le processus est commun à toutes les entreprises de votre secteur. Tout le reste relève du jugement, et c'est ce jugement que nous décomposons ci-dessous.

Notre guide principal du développement logiciel sur mesure couvre coûts, méthode et délais de bout en bout ; nous approfondissons ici une seule question de ce guide : quand créer un logiciel sur mesure plutôt que de s'abonner à un outil qui convient presque. Vous trouverez un arbre de décision applicable à votre propre situation, cinq scénarios tirés de vrais arbitrages créer-ou-acheter, et une liste honnête de raisons d'attendre.

L'arbre de décision créer ou acheter : quatre questions dans l'ordre

Parcourez-les dans l'ordre. Chaque question clôt la décision ou vous passe à la suivante. Sauter des étapes, c'est ainsi que des entreprises se persuadent de construire ce dont elles n'avaient pas besoin, ou de s'abonner à ce qui leur coûtera discrètement pendant des années.

Question 1 : est-ce un processus banalisé ?

La paie, la comptabilité, l'e-mail, les agendas sont des problèmes résolus. Toutes les entreprises en ont besoin, et ils fonctionnent de la même façon presque partout. Si votre réponse est oui, arrêtez-vous là et achetez. Aucun développement sur mesure ne bat un produit mûr sur un processus où personne ne se différencie.

Si le processus est propre au fonctionnement réel de votre entreprise, passez à la question deux.

Question 2 : un outil du commerce le couvre-t-il à 90 % ou plus, proprement ?

Pas « le couvre si nous adaptons notre processus au logiciel ». Le couvre tel que votre processus tourne déjà, sans tableur parallèle, sans étape manuelle d'export et de remise en forme, sans contournement que quelqu'un entretient de mémoire. Si un outil vous y amène vraiment, achetez-le et passez à autre chose. Une fine couche sur mesure greffée sur un produit qui convient à 90 % coûte souvent moins cher qu'un développement complet, et mérite un cadrage à part.

Si l'écart est le contournement lui-même, la double saisie, l'étape de correction manuelle, passez à la question trois.

Question 3 : ce processus est-il votre avantage concurrentiel ?

Certains écarts sont agaçants mais invisibles pour vos clients. D'autres sont exactement ce qui fait qu'un client vous choisit plutôt que le fournisseur suivant : votre délai de devis, votre fiabilité de préparation, votre capacité à gérer une exception sur laquelle le logiciel d'un concurrent s'étrangle. Si l'écart se loge là où personne d'autre que votre équipe opérationnelle ne le remarque, penchez quand même pour l'achat, ou essayez d'abord une couche low-code. Si l'écart touche le processus qui vous fait gagner des affaires, passez à la question quatre.

Question 4 : avez-vous trois ans ou plus devant vous pour l'utiliser ?

Un développement sur mesure est un actif pluriannuel, pas un achat ponctuel. Il doit rembourser son coût face au contournement qu'il remplace, et ce calcul a besoin de temps. Si votre équipe, votre processus ou la direction de votre entreprise risque de changer substantiellement d'ici un an ou deux, la réponse est pas encore, pas jamais. Si le processus existera encore à peu près sous sa forme actuelle dans trois ans ou plus, construisez.

Franchissez les quatre portes et la décision est de construire. Échouez à une seule et la réponse honnête est d'acheter, d'attendre, ou de colmater avec une couche low-code. Les scénarios ci-dessous montrent comment cela se joue sur de vraies demandes.

Cinq scénarios : ce que dit l'arbre en pratique

Scénario 1 : l'outil de devis à prix par paliers d'un distributeur. Verdict : construire. Un distributeur de 40 personnes chiffre chaque client selon des remises par volume à paliers, des exceptions propres à chaque client et des surcharges de fret qui varient par trajet. Aucun outil CPQ standard ne modélise les trois à la fois sans un tableur entretenu derrière. L'écart, c'est ce tableur : deux personnes le mettent à jour à la main, et un mauvais palier coûte de la marge sur chaque commande qu'il touche. La rapidité et la justesse des devis sont précisément ce que les clients remarquent : c'est un processus d'avantage concurrentiel avec plus de trois ans de vie devant lui. Construire.

Scénario 2 : paie et suivi du temps pour une agence de 15 personnes. Verdict : acheter. Rien dans la façon dont cette agence gère la paie ne diffère de n'importe quelle autre entreprise de 15 personnes. Un logiciel de paie du marché, ou un secrétariat social côté belge, couvre entièrement bulletins, DSN, virements et suivi du temps, sans contournement. Personne ne construit sa propre DSN : la règle change quand le législateur le décide, et vous porteriez seul le coût de chaque mise à jour. Cela échoue net à la question un. Acheter ici n'est pas un compromis : c'est la bonne réponse, et l'argent économisé revient au processus qui différencie réellement l'entreprise.

Scénario 3 : un tableau de bord interne alimenté par quatre outils SaaS. Verdict : pas encore, passez par le low-code. Une équipe opérationnelle veut un seul tableau de bord au lieu de quatre connexions. Le besoin de reporting est réel, mais personne ne sait encore quels indicateurs compteront une fois l'équipe restructurée au prochain trimestre, et les outils SaaS sous-jacents eux-mêmes pourraient changer. Cela passe la question deux (aucun tableau de bord du commerce ne couvre un mélange sur mesure de quatre outils) mais cale à la question quatre : l'horizon est incertain. Une plateforme low-code (Retool, Power Apps et outils similaires évoluent sur un marché que Gartner projette en croissance continue vers 44,5 milliards de dollars d'ici 2026) met un tableau de bord fonctionnel en ligne en quelques jours et se reconstruit à bas coût une fois la forme de l'équipe stabilisée. Revoyez un développement sur mesure quand les besoins de reporting auront tenu deux trimestres d'affilée.

Scénario 4 : un tableau de répartition logistique pour une flotte mixte. Verdict : construire. Un transporteur régional utilise un TMS standard qui gère bien la répartition monomodale, mais se casse sur les exceptions multimodales que sa flotte rencontre chaque jour : un chargement qui passe du camion au rail en cours de route, un changement de conducteur que le logiciel ne représente qu'avec une note manuelle. La précision de la répartition est le vrai différenciateur de l'entreprise face à des concurrents plus gros aux tournées moins flexibles. La composition de la flotte ne changera pas de sitôt. Toutes les portes passent. Construire.

Scénario 5 : un portail clients pour une startup de deux personnes sans revenus. Verdict : pas encore. Un fondateur veut un portail clients soigné avant même que le produit ait des clients payants pour valider les fonctionnalités dont ce portail a besoin. Les exigences bougent encore chaque semaine, personne n'a fait tourner le vrai parcours client assez longtemps pour le décrire précisément, et il n'y a pas encore de revenus pour financer trois ans d'usage. Cela échoue à la question quatre pour une raison structurelle : il n'existe pas de processus stable sur lequel amortir un développement. Un outil gratuit ou un simple formulaire fait entrer les premiers clients ; construisez le vrai portail quand le parcours cessera de changer à chaque sprint.

Les signes qu'il ne faut pas encore créer de logiciel sur mesure

Un conseil qui ne vous dit que quand construire ne joue pas franc jeu avec vous. Certains des signaux de construction les plus nets se révèlent prématurés dès qu'on y regarde de près.

• Vous ne savez pas encore décrire le processus en une page. Si écrire « comment le devis devrait fonctionner » fait remonter un désaccord au sein de votre propre équipe, le logiciel sur mesure gravera ce désaccord dans le marbre au lieu de le résoudre. Fixez d'abord le processus sur papier, même dans un tableur, avant de payer pour l'encoder dans du logiciel.
• Vous construisez parce qu'un concurrent a construit quelque chose, pas à cause de votre propre douleur. Copier l'outil d'un concurrent sans votre propre contournement, votre propre coût et votre propre réclamation client derrière, cela revient en général à résoudre son problème, pas le vôtre. Trouvez votre propre version de l'écart avant de commander un remède.
• Le contournement ne vous a rien coûté que vous puissiez pointer du doigt. « Cela nous agace » n'est pas « cela coûte douze heures par semaine et une facture erronée par mois ». Si vous ne savez pas nommer le coût, vous ne pouvez probablement pas encore justifier le projet non plus. Mesurez le coût pendant un mois ; le chiffre justifiera le projet ou vous en dissuadera.
• Personne dans votre équipe, ni chez votre prestataire, n'assume ce qui vient après le lancement. Un logiciel a besoin d'une personne qui traite la prochaine demande de fonctionnalité, surveille la prochaine intégration qui casse, et décide de ce qui change et de ce qui ne change pas. Un outil sans responsable d'aucun côté se dégrade en silence jusqu'à ce que plus personne ne lui fasse confiance.

Si deux de ces signes ou plus décrivent votre situation, attendez. Réglez le problème le moins cher (le processus, la visibilité du coût, la question du responsable) avant de régler le plus cher.

Questions fréquentes sur le choix entre créer et acheter

Comment savoir si je dois créer un logiciel sur mesure ou l'acheter ?

Achetez si un outil standard couvre votre processus sans contournement, ou si le processus est commun à toutes les entreprises. Construisez quand le processus vous est propre, que l'écart coûte cher, que le processus est votre avantage concurrentiel et qu'il gardera sa forme actuelle pendant trois ans ou plus.

Quel est le cadre de décision créer ou acheter ?

Une séquence de quatre questions : le processus est-il banalisé, un outil du commerce le couvre-t-il proprement, est-il votre avantage concurrentiel, et avez-vous trois ans ou plus pour l'utiliser. Ne construisez que si chaque question pointe vers la construction ; un seul non pointe vers l'achat ou l'attente.

Le logiciel sur mesure est-il toujours plus cher que le logiciel acheté ?

Pas dans la durée. Un abonnement paraît moins cher au mois, mais cumulé sur plusieurs outils pendant trois ans, il dépasse souvent un développement sur mesure à prix fixe, surtout une fois comptés les frais par utilisateur et le travail de contournement. Le chiffre initial et le chiffre à trois ans pointent fréquemment dans des directions opposées.

Combien de temps attendre avant de créer un logiciel sur mesure ?

Attendez que le processus à encoder ait gardé à peu près la même forme pendant deux trimestres, et que vous sachiez nommer un coût précis créé par le contournement actuel. Construire contre un processus qui change encore chaque semaine, c'est en général reconstruire dans l'année.

Puis-je commencer avec un logiciel du commerce et passer au sur mesure plus tard ?

Oui, et c'est souvent le bon ordre. Les outils du commerce ou low-code valident vite et à bas coût qu'un processus mérite un développement. Une fois le coût du contournement établi et le processus stabilisé, un développement sur mesure remplace la solution provisoire par un outil taillé exactement sur votre façon de travailler.

Passez votre propre situation dans cet arbre

Décrivez le processus, l'outil que vous utilisez aujourd'hui et l'endroit où le contournement apparaît, et nous vous dirons honnêtement de quel côté de l'arbre vous tombez. Si c'est construire, vous recevez un périmètre fixe, un forfait à prix fixe et une date de livraison en semaines, cadré comme nous le décrivons dans comment nous cadrons, construisons et vérifions. Si c'est acheter, nous vous le dirons.

Demander un devis à prix fixe →