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

Optez pour un logiciel sur mesure lorsque le processus vous appartient en propre, qu’aucun outil standard ne le couvre sans détour, et que vous avez l’horizon nécessaire pour l’exploiter pendant plusieurs années. Achetez quand une solution existante convient déjà, ou lorsque le processus est commun à l’ensemble de votre secteur. Tout le reste relève du discernement.

Notre présentation générale du développement logiciel sur mesure aborde coûts, méthode et délais de bout en bout. La question traitée ici est plus étroite : quand créer un logiciel sur mesure plutôt que de souscrire à un outil qui répond presque à vos besoins.

L’arbre décisionnel « créer ou acheter » : quatre questions à suivre dans l’ordre

Répondez-y dans l’ordre. Chaque question tranche, ou renvoie à la suivante. Sauter des étapes, c’est ainsi que des entreprises se convainquent de développer ce dont elles n’ont pas besoin, ou de s’engager dans un abonnement qui leur coûtera discrètement pendant des années.

Première question : s’agit-il d’un processus standardisé ?

La paie, la comptabilité, les e-mails ou la gestion d’agendas sont des problèmes résolus. Toutes les entreprises en ont besoin, et ces processus fonctionnent de manière quasi identique partout. Si la réponse est oui, arrêtez-vous là et achetez. Aucun développement sur mesure ne rivalisera avec un produit mature sur un processus où personne ne se différencie.

Si le processus est propre à votre entreprise, passez à la deuxième question.

Deuxième question : un outil du marché le couvre-t-il à 90 % ou plus, sans compromis ?

Pas « le couvre si nous adaptons notre processus au logiciel ». Le couvre tel que votre processus fonctionne déjà, sans tableur parallèle, sans export manuel ni étape de mise en forme, sans contournement maintenu empiriquement. Comme le rappelle France Num, les doubles saisies et les transferts manuels de données génèrent des erreurs et une perte de productivité. Si un outil y répond vraiment, achetez-le et passez à autre chose. Une fine couche sur mesure greffée sur un produit adapté à 90 % coûte souvent moins cher qu’un développement complet, et mérite une analyse distincte. Avant d’écarter une solution existante, France Num recommande d’évaluer son degré de couverture fonctionnelle, ses possibilités d’intégration et le coût de son paramétrage.

Si l’écart se résume à des contournements, des doubles saisies ou des corrections manuelles, passez à la troisième question.

Troisième question : ce processus constitue-t-il votre avantage concurrentiel ?

Certains écarts sont gênants, mais invisibles pour vos clients. D’autres sont précisément ce qui vous distingue : votre rapidité à établir un devis, votre fiabilité dans la préparation des commandes, ou votre capacité à gérer une exception qui bloque le logiciel d’un concurrent. Si l’écart se situe là où seule votre équipe opérationnelle le remarque, privilégiez l’achat ou testez d’abord une solution low-code. Si l’écart touche au processus qui vous fait gagner des affaires, passez à la quatrième question.

Quatrième question : avez-vous au moins trois ans devant vous pour l’utiliser ?

Un développement sur mesure est un investissement pluriannuel, pas un achat ponctuel. Chez Globaprom, nous utilisons trois ans comme horizon pragmatique pour évaluer l’amortissement et la stabilité du besoin, sans en faire une règle absolue. Il doit rentabiliser son coût face aux contournements qu’il remplace, et ce calcul prend du temps. Si votre équipe, votre processus ou la stratégie de votre entreprise risque d’évoluer significativement d’ici un ou deux ans, 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.

Si vous franchissez ces quatre étapes, la décision est de construire. Si vous échouez à l’une d’elles, la réponse honnête est d’acheter, d’attendre ou de combler le besoin avec une solution low-code. Les scénarios ci-dessous montrent comment cela se traduit dans des cas concrets.

Cinq scénarios : ce que révèle l’arbre décisionnel en pratique

Scénario 1 : l’outil de devis à tarifs par paliers d’un distributeur. Verdict : construire. Un distributeur de 40 personnes établit ses devis en fonction de remises par volume à paliers, d’exceptions propres à chaque client et de surcoûts logistiques variables selon les trajets. Aucun outil CPQ standard ne gère ces trois éléments simultanément sans recourir à un tableur maintenu en parallèle. L’écart, c’est précisément ce tableur : deux personnes le mettent à jour manuellement, et une erreur de palier grignote la marge sur chaque commande concernée. La rapidité et la précision des devis sont exactement ce que les clients remarquent : c’est un processus clé de différenciation, avec une durée de vie prévisible de plus de trois ans. Construire.

Scénario 2 : paie et suivi du temps pour une agence de 15 personnes. Verdict : acheter. Rien, dans la gestion de la paie de cette agence, ne la distingue d’une autre entreprise de même taille. Un logiciel de paie du marché, ou un secrétariat social en Belgique, couvre entièrement les bulletins, les déclarations sociales, les virements et le suivi du temps, sans contournement. Personne ne développe sa propre déclaration sociale. En Belgique, la DmfA est transmise chaque trimestre à l’ONSS, le plus souvent par le secrétariat social ; en France, l’Urssaf exige chaque mois la DSN, produite à partir du logiciel de paie et transmise par l’employeur ou son expert-comptable. Les règles évoluent au gré du législateur, et vous supporteriez seul le coût de chaque mise à jour. Cela échoue dès la première question. Acheter ici n’est pas un compromis : c’est la bonne décision, et l’argent économisé peut être réinvesti dans le processus qui différencie vraiment 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 souhaite regrouper quatre connexions en un seul tableau de bord. Le besoin de reporting est réel, mais personne ne sait encore quels indicateurs seront pertinents une fois l’équipe restructurée au trimestre suivant, et les outils SaaS sous-jacents pourraient eux-mêmes changer. Cela passe la deuxième question (aucun tableau de bord standard ne couvre un assemblage sur mesure de quatre outils), mais bloque à la quatrième : l’horizon est trop incertain. Une plateforme low-code (Retool, Power Apps ou équivalent) est particulièrement adaptée pour tester ou faire évoluer rapidement une première solution : elle permet de déployer un tableau de bord fonctionnel en un temps record et de le reconstruire à moindre coût une fois la structure de l’équipe stabilisée. Dans une prévision publiée en 2022, Gartner estimait que le marché mondial des technologies low-code atteindrait 44,5 milliards de dollars en 2026, avec une croissance annuelle de 19 %. Envisagez un développement sur mesure seulement lorsque les besoins de reporting auront conservé la même forme pendant deux trimestres consécutifs.

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 bloque sur les exceptions multimodales rencontrées quotidiennement par sa flotte : un chargement passant 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 véritable atout de l’entreprise face à des concurrents plus grands, aux tournées moins flexibles. La composition de la flotte ne changera pas de sitôt. Toutes les conditions sont remplies. Construire.

Scénario 5 : un portail clients pour une startup de deux personnes sans revenus. Verdict : pas encore. Un fondateur souhaite développer un portail clients sophistiqué avant même que son produit n’ait des clients payants, pour valider les fonctionnalités nécessaires. Les exigences évoluent encore chaque semaine, personne n’a testé le 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’utilisation. Cela échoue à la quatrième question pour une raison structurelle : il n’existe pas de processus stable sur lequel amortir un développement. Un outil gratuit ou un simple formulaire suffit pour accueillir les premiers clients. Construisez le vrai portail quand le parcours cessera d’évoluer à chaque sprint.

Les signaux indiquant qu’il est trop tôt pour créer un logiciel sur mesure

Un conseil qui ne vous indique que quand construire ne joue pas cartes sur table. Certains des signaux les plus évidents en faveur d’un développement se révèlent prématurés dès qu’on les examine de près.

• Vous ne parvenez pas à décrire le processus en une page. Si rédiger « comment devrait fonctionner le devis » fait émerger des désaccords au sein de votre équipe, un logiciel sur mesure gravera ces désaccords dans le marbre au lieu de les résoudre. Fixez d’abord le processus sur papier, même dans un tableur, avant d’investir dans son implémentation logicielle. Avant de déployer un outil de gestion, France Num recommande de lister les processus métiers existants, de clarifier les objectifs et de formaliser les besoins.
• Vous construisez parce qu’un concurrent l’a fait, et non à cause d’une difficulté qui vous est propre. Copier l’outil d’un concurrent sans avoir identifié votre propre contournement, votre propre coût ou votre propre insatisfaction client revient généralement à résoudre son problème, pas le vôtre. Identifiez d’abord votre version de l’écart avant de commander une solution.
• Le contournement ne vous coûte rien de quantifiable. « Cela nous agace » n’équivaut pas à « cela nous coûte douze heures par semaine et une facture erronée par mois ». Si vous ne pouvez pas chiffrer le coût, vous ne pourrez probablement pas justifier le projet non plus. Mesurez ce coût pendant un mois : le résultat vous convaincra de lancer le projet ou de l’abandonner.
• Personne dans votre équipe, ni chez votre prestataire, ne prend en charge ce qui vient après le lancement. Un logiciel a besoin d’une personne pour traiter les demandes d’évolution, surveiller les intégrations défaillantes et décider de ce qui change ou non. La CNIL recommande notamment de tester les mises à jour, de tenir une documentation et des règles de codage pour maintenir l’application et corriger efficacement les dysfonctionnements. Un outil sans responsable des deux côtés se dégrade silencieusement, jusqu’à ce que plus personne ne lui fasse confiance.

Si deux de ces signaux ou plus s’appliquent à votre situation, attendez. Résolvez d’abord le problème le moins coûteux (le processus, la visibilité du coût, la question du responsable) avant d’aborder le plus onéreux.

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

Appliquez cet arbre décisionnel à votre situation

Décrivez le processus, l’outil que vous utilisez aujourd’hui et l’endroit où apparaît le contournement. Nous vous dirons honnêtement de quel côté de l’arbre vous vous situez. Si c’est construire, vous recevrez un périmètre fixe, un forfait à prix fixe et une date de livraison en semaines, cadré comme nous l’expliquons dans notre méthode de cadrage, de construction et de recette. Si c’est acheter, nous vous le dirons sans détour.

Demander un devis à prix fixe →