Pendant longtemps, la règle a tenu en une phrase : on ne construit jamais ce qu'on peut louer. Écrire un logiciel prenait des mois, et un abonnement SaaS livrait l'équivalent le lendemain, entretenu par quelqu'un d'autre. Pour une PME, faire bâtir un logiciel sur mesure restait un luxe, réservé aux cas où rien n'existait sur le marché.
Une moitié de ce calcul a changé. Les outils de développement assistés par l'IA ont fait fondre le coût d'une première version. L'autre moitié n'a pas bougé : un logiciel en service doit être hébergé, mis à jour et sauvegardé, et quelqu'un doit répondre quand il casse.
Cet article propose quatre tests pour trancher, en tenant compte des deux moitiés.
La réponse courte, pour les pressés
Une PME devrait faire construire son propre logiciel quand le processus visé la distingue de ses concurrents, quand le prix par siège d'un SaaS grimpe avec son effectif pour des fonctions qu'elle n'utilise pas, quand son équipe recopie des données d'un outil à l'autre, ou quand elle veut décider elle-même où vivent ses données. Elle devrait louer tout le reste : comptabilité, paie, courriel, CRM pour un processus de vente standard. Dans notre pratique, l'IA a ramené le coût d'écrire une première version simple à quelques jours. Elle n'a pas réduit le coût de posséder un logiciel : hébergement, correctifs de sécurité, sauvegardes, soutien, migration des données. La Loi 25 ne tranche pas à votre place : son article 3.3 exige une évaluation des facteurs relatifs à la vie privée pour l'acquisition comme pour le développement d'un système qui traite des renseignements personnels. Souvent, la bonne réponse est hybride : garder les SaaS standards et construire la mince couche qui vous appartient.
Ce que l'IA a changé, et ce qu'elle n'a pas changé
En plus des sites de nos clients, on construit et on exploite nos propres logiciels. Caribooks, un connecteur entre QuickBooks et un assistant IA, est passé de l'idée à un produit en ligne qui facture en une seule journée de travail. Type Parts, un générateur de pièces CAO, a été construit en quatre jours. Ce sont nos observations, pas une statistique, mais elles suffisent à casser la vieille règle.
L'article où on raconte pourquoi on construit nos propres logiciels décrit aussi l'autre extrême. ForgeMRP, notre logiciel de planification de production, tourne depuis deux ans avec de vraies données. Là, le coût vient des erreurs qu'on découvre une fois que des gens y travaillent chaque jour, sur des données qu'on ne peut pas perdre. L'écriture est devenue la partie la moins chère.
Posséder un logiciel, c'est payer cinq choses que l'abonnement cachait dans son prix. L'hébergement, chaque mois. Les correctifs de sécurité des composants dont il dépend, qui arrivent sans prévenir. Les sauvegardes, et le test qui prouve qu'on sait les restaurer. Une personne qui répond quand ça casse, un mardi à 7 h. Et la reprise des données du système que vous quittez, presque toujours le poste qu'on sous-estime. L'IA accélère un peu chacun de ces postes sans en supprimer aucun.
À « peut-on se permettre de le construire? », la réponse est maintenant souvent oui. La question utile devient : « veut-on posséder ça pendant cinq ans? »
Premier test : ce processus vous distingue-t-il?
Un SaaS est une moyenne. Il codifie la façon dont des milliers d'entreprises font la même chose, et c'est exactement ce que vous voulez pour la paie, la comptabilité ou le courriel.
Le calcul change pour le processus qui fait votre réputation : la façon dont vous montez une soumission à partir de vos coûts réels, dont vous planifiez un atelier, dont vous tenez un client informé de son dossier. Si votre équipe a déjà plié un SaaS dans tous les sens pour qu'il épouse ce processus, avec des champs détournés et un fichier Excel à côté, c'est un signal. Le logiciel vous impose sa moyenne sur la seule chose où vous n'êtes pas moyen.
Le piège inverse existe aussi. Beaucoup de processus qu'on croit uniques ne le sont pas. Un critère simple : si un client remarque la différence, le processus vous distingue. Si seul votre comptable la remarque, louez.
Deuxième test : le prix par siège, à votre effectif
La plupart des SaaS d'affaires facturent par utilisateur. Indolore à trois personnes, le modèle l'est beaucoup moins à vingt : la facture suit l'effectif, pas la valeur que l'outil vous rend.
Un exemple relevé le 24 septembre 2026 sur la page de prix de HubSpot : le forfait Sales Hub Professional y démarre à 117 $ CA par siège par mois en facturation annuelle (130 $ en paiement mensuel avec engagement annuel), plus des frais de démarrage obligatoires, payés une seule fois, de 1 950 $ CA. Pour dix vendeurs, en annuel, c'est 14 040 $ par année, et 15 990 $ la première avec les frais de démarrage. Pour vingt, 28 080 $. Le prix n'est pas abusif; la question est de savoir quelle part de l'outil vous sert vraiment.
Additionnez vos abonnements par siège sur trois ans, à l'effectif que vous prévoyez et non à celui d'aujourd'hui. Soulignez les fonctions que votre équipe utilise réellement. Si la liste soulignée tient en quelques écrans et que le total est élevé, un outil sur mesure mérite au moins une conversation. Si la liste est longue, ou si vous comptez sur ce que le fournisseur améliore chaque trimestre, restez.
Un logiciel sur mesure a une courbe de coûts différente, pas forcément plus basse : elle suit sa complexité, pas le nombre de personnes qui s'y connectent. Ajouter un employé n'y coûte presque rien. Ajouter une fonction, oui.
Troisième test : combien d'outils recopiez-vous à la main?
Le symptôme le plus fiable se cache dans le temps de votre équipe. Une commande entre par la boutique en ligne, quelqu'un la ressaisit dans le système de production, puis dans QuickBooks, puis écrit au client pour lui dire où elle en est. Chaque outil est correct pris isolément. Le coût est dans les coutures.
C'est souvent là que le sur mesure paie le plus, et rarement en remplaçant un SaaS. On garde QuickBooks, le CRM et Stripe, et on construit la mince couche qui les relie et qui porte votre façon de travailler : une intégration qui synchronise, un outil interne qui remplace le fichier partagé, un portail où vos clients consultent l'état de leur dossier au lieu de vous écrire. Cette couche est petite, elle vous appartient, et les fournisseurs gardent le travail qu'ils font bien.
Avant d'écrire une ligne de code, vérifiez si un outil d'automatisation suffit. Pour un flux linéaire et prévisible, un outil no-code fait le travail; on a détaillé où passe la limite dans notre comparaison entre no-code et sur mesure. Dans l'écosystème Microsoft, Copilot Studio couvre aussi une partie des besoins.
Quatrième test : où vivent vos données, et comment on en sort
La Loi 25 est plus neutre qu'on le croit. L'article 3.3 de la Loi sur la protection des renseignements personnels dans le secteur privé exige une évaluation des facteurs relatifs à la vie privée pour « tout projet d'acquisition, de développement et de refonte de système d'information » qui traite des renseignements personnels. Acheter un SaaS et faire construire un outil déclenchent la même obligation. Le même article ajoute une exigence méconnue : le projet doit permettre qu'un renseignement personnel informatisé recueilli auprès d'une personne lui soit communiqué « dans un format technologique structuré et couramment utilisé ». Loué ou bâti, le système doit savoir exporter proprement les données d'une personne.
La différence est dans le contrôle. Avec un SaaS, vous évaluez le fournisseur : où il héberge, à quels sous-traitants il confie vos données, et s'il les conserve hors du Québec, auquel cas la loi exige une évaluation préalable et une entente écrite (art. 17). Avec un outil sur mesure, vous choisissez vous-même l'hébergeur et la région, et l'évaluation porte sur des décisions que vous avez prises.
Reste le coût de sortie, le poste oublié des deux côtés. En quittant un SaaS, vérifiez ce qui s'exporte réellement : les données brutes, souvent; l'historique, les pièces jointes et les automatisations, pas toujours. En confiant un projet à un développeur, posez les questions symétriques : à qui appartient le code, au nom de qui sont les comptes d'hébergement et la base de données, et qui d'autre pourrait reprendre le système demain. Un logiciel sur mesure dont vous ne contrôlez ni le code ni les comptes est un SaaS avec un seul client, et moins de garanties.
Quand louer reste la bonne réponse
La plupart des PME devraient louer la plupart de leurs logiciels. Trois situations penchent nettement vers l'abonnement.
La fonction est réglementée et change souvent : paie, taxes, comptabilité. Le fournisseur absorbe les changements de règles pour des milliers de clients à la fois. En commerce en ligne, c'est le même raisonnement, détaillé dans Shopify ou boutique sur mesure : tant que votre besoin est standard, la plateforme gagne.
Personne chez vous ne peut posséder l'outil. Un logiciel sur mesure a besoin d'un responsable à l'interne, qui décide de ce qu'il doit faire et remarque quand il ne le fait plus. Sans cette personne, même un bon outil dérive.
Le processus n'est pas encore stable. Si votre façon de travailler change tous les trois mois, la figer dans du code est prématuré. Un SaaS souple, ou un tableur bien tenu, vous laisse apprendre avant de construire.
Par où commencer
Faites les quatre tests sur un seul processus, pas sur toute l'entreprise. Choisissez celui qui génère le plus de ressaisies ou de courriels de suivi, calculez ce que vous payez en abonnements pour le soutenir, et notez où ses données vivent aujourd'hui. Si trois tests sur quatre pointent vers le sur mesure, sautez le cahier des charges de quarante pages : construisez une petite première version et mettez-la devant ceux qui l'utiliseront.
C'est le travail qu'on fait chez Peich : des portails clients, des outils internes et des intégrations avec les systèmes que vous utilisez déjà, livrés par cycles de deux semaines, puis hébergés et entretenus par l'équipe qui les a écrits. Apportez-nous le processus qui vous coûte le plus de ressaisies : on fera les quatre tests avec vous, et on vous dira aussi quand la réponse est de louer.
Écrit parXavier Peich