Logiciel sur mesure ou prêt à l’emploi : les trois seules questions qui comptent

Achetez quand le problème est courant, que la catégorie est mûre et que votre version du problème est ordinaire — comptabilité, paie, courriel, signature électronique, service d’assistance. Bâtissez quand le processus est précisément ce pour quoi vos clients vous paient, quand aucun produit ne modélise votre objet central, ou quand tous les outils de la catégorie supposent une entreprise structurée autrement que la vôtre. Tout le reste relève de la configuration, qui n’est ni l’un ni l’autre et qui est généralement la bonne réponse la moins chère.

Faut-il acheter un logiciel ou le faire bâtir?

Comment décider :

La fonction est standard partout — comptabilité, paie, signature électronique, courriel. Acheter. Vous ne ferez jamais mieux qu’une catégorie mûre, et vous distinguer ici n’a aucune valeur commerciale.

La catégorie existe et un produit couvre l’essentiel de votre processus. Configurer. La plupart des projets de développement auraient dû être des projets de configuration. Épuisez d’abord ce que le produit peut faire.

Le processus est ce qui vous distingue vraiment, et vos clients le sentent. Bâtir. Confier ce qui vous distingue à un produit que chaque concurrent peut aussi acheter fait disparaître la raison de vous choisir.

Tous les produits de la catégorie supposent une entreprise structurée autrement que la vôtre. Bâtir. C’est le signal honnête. Si quatre fournisseurs modélisent tous la chose de la même mauvaise façon, aucune configuration n’y changera rien.

Vous avez un tableur qui fait tourner quelque chose d’important et personne n’ose y toucher. Bâtir. Ce tableur est déjà un logiciel sur mesure. Simplement, c’est un logiciel sur mesure sans tests, sans permissions et avec un seul responsable.

La réglementation exige une piste de vérification que le produit ne peut pas produire. Bâtir. Il est impossible d’ajouter après coup un historique vérifiable à un système qui ne l’a jamais enregistré.

Ce qui fait varier le coût :

La portée, pas la technologie. Le coût d’un développement dépend presque entièrement de la part de l’entreprise que vous essayez de modéliser d’un coup. La même équipe, la même technologie et le tiers de la portée, c’est le tiers du coût et le dixième du risque.

Le nombre d’intégrations. Chaque système avec lequel le nouveau doit communiquer ajoute du coût et de l’entretien permanent. Deux intégrations, c’est un projet; huit, c’est un chantier.

La qualité de la migration des données. Migrer des données propres est simple. Migrer quinze ans de fiches incohérentes est souvent le poste le plus important, et on le découvre tard.

Qui en assure l’entretien ensuite. Un logiciel sur mesure a un coût d’exploitation même quand rien ne change. Budgéter le développement sans l’entretien, c’est comme ça que les systèmes deviennent désuets en deux ans.

Les erreurs courantes :

Tout bâtir d’un coup. La recette qui fonctionne : un seul objet problématique d’abord, en production, qui fait ses preuves, avant d’ajouter quoi que ce soit. Les développements livrés tout d’un coup échouent à cause de la portée, pas du code.

Acheter pour éviter de décider. Acheter une plateforme parce que c’est le choix sûr, puis passer deux ans à la configurer dans une forme qui lui résiste, coûte plus cher que l’une ou l’autre des options honnêtes.

Croire qu’un tableur ne coûte rien. Le tableur a un coût : les heures, les erreurs, et le fait que le départ d’une seule personne emporte le processus avec elle. Comparez à ça, pas à zéro.

Un logiciel sur mesure coûte-t-il toujours plus cher?

Au départ, généralement oui. Sur cinq ans, avec des licences par utilisateur et un consultant en configuration sous contrat permanent, souvent non. La réponse honnête exige de modéliser votre vrai nombre d’utilisateurs et d’années plutôt que de comparer un prix affiché à une soumission.

Quel est le plus petit développement sur mesure raisonnable?

Un objet et un flux de travail qui vivent actuellement dans un tableur, en production, utilisés tous les jours. Si une entreprise ne peut pas livrer ça rapidement, une portée plus large avec la même entreprise ne se passera pas mieux.

Comment éviter de se retrouver avec un logiciel désuet?

Soyez propriétaire du code, gardez une technologie sans surprise et répandue, exigez de la documentation, et assurez-vous que plus d’une personne peut faire fonctionner le système. La plupart des histoires d’horreur de systèmes désuets relèvent de la propriété et du personnel plutôt que de la technologie.

L’IA devrait-elle changer cette décision?

Elle réduit le coût de développement, ce qui déplace la ligne — des choses qui ne valaient pas la peine d’être bâties en 2022 le valent maintenant. Elle ne change pas la logique : les fonctions standard devraient toujours être achetées.

Dernière révision le 22 août 2026