Sept outils SaaS ou un seul système ? Quand le sur-mesure devient rentable

Le SaaS est le moyen le moins cher de démarrer. Quelques années plus tard, un même parcours commercial traverse pourtant cinq à sept outils, et l’entreprise finance un grand système par fragments sans l’avoir jamais acheté. La façon dont cette situation s’installe a déjà été décrite dans l’article Votre entreprise n’a pas besoin de plus de logiciels. Elle a besoin de moins de chaos. Ce texte ne répète pas le diagnostic, il traite ce qui vient après : comment décider et comment défendre la décision avec des chiffres.

La comparaison logiciel sur mesure entreprise vs SaaS peut se calculer de façon à tenir devant le dirigeant comme devant le comptable. La plupart des entreprises tranchent pourtant à partir des deux chiffres qui renseignent le moins sur le coût réel : l’abonnement mensuel et le prix inscrit dans le devis de développement. Les deux ne sont que des droits d’entrée dans plusieurs années d’exploitation.

Le sujet n’est pas le prix de la licence, mais le coût total de possession

Le total cost of ownership, en français le coût total de possession, est une méthode qui regarde au-delà du prix d’achat et intègre tout ce que l’acquisition et l’exploitation coûtent encore. Lisa M. Ellram l’a décrite au milieu des années quatre-vingt-dix à partir d’études de cas menées dans onze entreprises, et elle vaut pour le logiciel comme pour l’achat de matières : le prix n’est qu’une ligne parmi d’autres, et rarement la ligne décisive.

Que ce ne soit pas une nuance académique, l’enquête sur les coûts du cycle de vie de trente systèmes applicatifs informatiques, menée par Rüdiger Zarnekow et Walter Brenner de la University of St. Gallen, le montre clairement. Sur cinq années d’exploitation, les coûts récurrents d’exploitation, de support, de maintenance et d’évolution représentent 79 % des coûts du cycle de vie. La planification et le développement initial en représentent 21 %.

Or la plupart des décisions de type build ou buy se prennent sur la base de ce cinquième, parce que c’est précisément lui qui figure dans le devis. Le reste arrive plus tard et se dissout dans les salaires, dans le support et dans le temps des personnes qui finissent par débrouiller la situation. Deux postes sont d’ailleurs sous-estimés avec la même régularité : l’exploitation d’un système propriétaire et l’administration d’une pile d’abonnements qui grossit.

Ce qui doit réellement figurer dans le tableau de TCO

Un tableau de TCO comporte deux colonnes, le stack actuel et l’alternative proposée, avec les mêmes catégories dans les deux. Sinon, vous ne comparez pas deux solutions, mais deux façons de compter.

• Licences, consommation et sièges inutilisés. Au-delà du tarif mensuel, il faut regarder comment le prix se comporte quand l’entreprise grandit. Zylo, dans son SaaS Management Index 2026, indique que 78 % des responsables informatiques ont constaté des frais inattendus sur des tarifications à la consommation ou liées à l’IA, que 61 % ont dû renoncer à d’autres projets à cause d’une hausse imprévue des coûts et que les organisations laissent en moyenne 36 % de leurs licences SaaS inutilisées. La dépense SaaS médiane par salarié y est chiffrée à 9 455 USD, et l’édition précédente faisait état d’une croissance annuelle de 21,9 %. Ce sont des données issues de portefeuilles de grandes entreprises. Pour une PME, c’est la tendance qui compte, pas la valeur absolue.
• Intégrations et leur maintenance. Le MuleSoft Connectivity Benchmark Report de Salesforce indique qu’une organisation moyenne utilise 897 applications, que 29 % seulement sont connectées entre elles et que les équipes informatiques consacrent 39 % de leur temps à concevoir, construire et tester des intégrations sur mesure. Ce temps est un coût comme un autre, à ceci près que personne ne le facture.
• Travail humain entre les systèmes. Une recherche publiée dans la Harvard Business Review a suivi 137 personnes réparties dans vingt équipes de trois entreprises du classement Fortune 500. Elles basculaient entre applications et fenêtres environ 1 200 fois par jour, chaque bascule coûtait un peu plus de deux secondes, et le cumul représentait environ 9 % du temps de travail annuel passé à se réorienter. Dans le TCO, cela s’inscrit comme un taux horaire multiplié par des heures.
• Visibilité sur vos propres dépenses. Flexera, dans son State of ITAM Report 2026, indique que 43 % des organisations constatent une hausse annuelle des dépenses SaaS gaspillées, 59 % pour les logiciels d’IA, et que 36 % seulement disposent d’une visibilité complète sur leur environnement informatique. Sans elle, le TCO ne peut pas être calculé et la décision reste une supposition habillée en présentation.

Tout ne mérite pas d’être développé sur mesure

Développer son propre agenda, son client de messagerie ou son logiciel comptable serait, pour la plupart des entreprises, une allocation de capital absurde. La raison est économique : il s’agit de fonctions dont le développement est financé simultanément par des dizaines de milliers de clients. Eurostat indique qu’en 2025, 52,7 % des entreprises de l’UE utilisaient des services cloud payants, le plus souvent pour la messagerie (85,2 %) et pour les logiciels financiers ou comptables (58,2 %). À ce niveau de diffusion, personne ne reconstruit un tel coût unitaire pour son seul usage.

Le sur-mesure commence à avoir un sens économique là où le processus constitue un avantage concurrentiel : tarification, gestion des capacités, workflow commercial, portail client ou travail sur un modèle de données propriétaire. La bonne question n’est donc pas de savoir s’il faut construire ou acheter, mais : quelle partie de son fonctionnement l’entreprise doit-elle stratégiquement posséder ?

Il faut dire aussi ce qu’un prestataire de développement formule rarement. Une grande partie des demandes qui arrivent avec la phrase « il nous faut notre propre système » se règle à moindre coût : par un audit de licences, par une configuration sérieuse de l’outil que vous possédez déjà, par le déplacement d’un processus dans un seul système existant au lieu de trois, ou par un outil no-code, c’est-à-dire un environnement où la logique s’assemble sans programmation. Si le problème se résout pour un dixième du prix, le développement sur mesure est une mauvaise réponse. Et si c’est le processus lui-même qui est défaillant, un nouveau logiciel ne fera que l’accélérer, ce dont traite le texte L’IA ne sauvera pas un mauvais processus.

L’architecture la plus solide est souvent hybride

Une architecture moderne ne signifie pas que tout est programmé depuis zéro. L’entreprise conserve des services externes pour les paiements, la messagerie, la comptabilité ou l’authentification, et ne possède que la couche qui pilote son processus spécifique, ses données et son interface.

Le mécanisme est simple. La couche propriétaire définit le modèle de données, c’est-à-dire la façon dont l’entreprise nomme une commande, un client, une capacité et un prix. Les autres systèmes deviennent alors des fournisseurs de fonctions interchangeables, et non les propriétaires de la vérité sur l’entreprise. La différence apparaît au deuxième changement d’outil : l’intégration change, le processus ne change pas. L’hybride possède néanmoins sa propre ligne dans le tableau : il y a davantage d’interfaces à maintenir, pas moins.

« Un investissement unique » ne veut pas dire sans coûts ultérieurs

Un logiciel sur mesure n’est pas un actif sans entretien. Il exige de l’hébergement, du monitoring, des mises à jour de sécurité et un développement continu. La différence avec l’abonnement tient à ce que l’investissement crée un actif sous votre contrôle, pas à la disparition des coûts récurrents.

S’y ajoute le risque d’exécution, rarement présent dans les devis. Bent Flyvbjerg et Alexander Budzier ont analysé un échantillon de 1 471 projets informatiques et constaté un dépassement budgétaire moyen de 27 %. La forme de la distribution importe davantage : un projet sur six s’est révélé être un cygne noir, avec un dépassement moyen des coûts de 200 % et du calendrier de près de 70 %. Le risque ne se situe donc pas dans la moyenne, mais dans la queue de distribution, et plus le périmètre engagé en une seule fois est large, plus la probabilité d’y atterrir augmente. D’où l’intérêt de construire par petites étapes et de recalculer, après chacune, si la suivante garde du sens.

Un business case sur trois à cinq ans

Sur un horizon d’un an, la décision est impossible. La solution propriétaire perd presque toujours la première année : elle porte la totalité de l’investissement et quasiment aucune économie. Modélisez trois à cinq ans et comparez des coûts cumulés, pas la première facture. Le modèle a besoin de quatre entrées :

1. La base. Ce que coûte le stack actuel, travail humain entre les systèmes inclus.
2. La courbe de croissance. Comment cette base se comporte avec deux fois plus de clients. Avec des licences facturées par utilisateur, elle croît linéairement ; avec une couche propriétaire, généralement pas.
3. L’investissement et son exploitation. Pas seulement le prix du développement, mais aussi ce qu’il coûtera pendant les cinq années suivantes.
4. Le point de bascule. L’année où les courbes cumulées se croisent, et ce qui se passe si elle se décale de douze mois.

Exemple modélisé. Les chiffres sont des hypothèses choisies pour illustrer le calcul, pas des mesures issues d’un projet réel. Une entreprise de 40 salariés pilote un processus de commande à travers six outils et paie 2 200 euros par mois de licences, soit 26 400 euros par an. Avec une croissance annuelle de quinze pour cent, cela représente environ 92 000 euros sur trois ans. Le devis pour la couche propriétaire s’élève à 70 000 euros. Si le ratio de l’étude de la University of St. Gallen s’y appliquait, où le développement initial représente 21 % des coûts sur cinq ans, la somme quinquennale se situerait autour de 330 000 euros, soit environ 66 000 euros par an.

Deux points comptent dans ce calcul. Le premier est méthodologique : 92 000 euros correspondent à trois ans, 330 000 euros à cinq ans, et seules des périodes de même durée sont comparables. À horizon identique, la solution propriétaire ressort ici plus chère, pas moins chère. Le second est inconfortable : les licences économisées ne financent pas, à elles seules, un tel écart. Le business case doit reposer sur de la capacité humaine libérée, sur le raccourcissement du délai de traitement d’une commande, sur des erreurs qui cessent de se produire ou sur un chiffre d’affaires que le stack actuel ne sait pas absorber. Si rien de tout cela ne peut être estimé, même grossièrement, le projet n’est pas mûr pour une décision.

L’investissement ne se compare d’ailleurs pas à zéro, mais à la meilleure alternative, qui est souvent un poste supplémentaire. Nous avons consacré un texte distinct à la question de savoir si l’entreprise a besoin d’un système ou d’un nouveau salarié.

Les signaux qui rendent le sur-mesure pertinent et ceux qui l’écartent

Le calcul en vaut la peine si plusieurs de ces points sont vrais

• Le processus concerné est une source d’avantage concurrentiel, pas une obligation administrative.
• Le coût croît linéairement avec le nombre de personnes ou de transactions, alors que l’apport de l’outil, lui, ne croît pas.
• Le fournisseur a modifié son modèle tarifaire ou supprimé une fonction sur laquelle repose votre processus.
• Votre offre est limitée par ce que l’outil autorise, pas par ce que le marché demande.

C’est une mauvaise réponse si l’un de ces points est vrai

• Il s’agit d’une fonction commoditisée qu’un service prêt à l’emploi traite tout aussi bien.
• L’entreprise n’a pas encore réalisé d’audit de licences et ignore combien elle paie aujourd’hui, et pour quoi.
• Les besoins changent tous les mois et personne ne sait les figer, même sur un trimestre.
• Personne, en interne, ne reprendra le système après la livraison ni n’en assumera la responsabilité.

Le coût de sortie n’est plus une inconnue, du moins dans l’UE

Le TCO inclut aussi ce que coûte le départ. Jusqu’à récemment, cette ligne ne pouvait pas être chiffrée, ce qui en faisait un argument fataliste du type « de toute façon, nous sommes prisonniers du fournisseur ». La réglementation a changé la donne. Selon la Commission européenne, le Data Act, c’est-à-dire le règlement (UE) 2023/2854, est applicable depuis le 12 septembre 2025 et facilite le transfert des données ainsi que le changement de fournisseur cloud. L’analyse juridique du cabinet Latham & Watkins précise que les obligations couvrent l’IaaS, le PaaS et le SaaS, et que depuis le 11 janvier 2024 les fournisseurs ne peuvent facturer des frais de migration qu’au titre de la refacturation des coûts directs, sans marge. À partir du 12 janvier 2027, ces frais seront totalement interdits.

Les conséquences sont doubles et ne vont pas dans le même sens. Le prix de la sortie baisse, donc le choix d’un service prêt à l’emploi devient moins risqué : un outil mal choisi peut être remplacé. Dans le même temps, la barrière au transfert des données vers une infrastructure propriétaire diminue, ce qui rend également la voie du sur-mesure moins coûteuse. Le tableau de TCO doit donc comporter une ligne avec le prix et le format de l’export. Cela se teste aujourd’hui, pas au moment de la rupture.

La décision entre système propriétaire et abonnement n’est pas une question de goût technologique, mais de savoir quelle partie de son fonctionnement l’entreprise veut posséder et si elle saura encore la payer dans trois ans. La réponse ne s’obtient pas auprès d’un éditeur de logiciels : il connaît son offre, pas vos chiffres. La première étape n’est donc pas le choix d’une technologie, mais un diagnostic : ce que coûte aujourd’hui votre stack, combien de travail humain il génère autour de lui et quelle part relève de la commodité.

Ce qu’il faut retenir

• Comparez des coûts totaux de possession, pas le prix d’un abonnement ni celui d’un développement. Selon l’étude de la University of St. Gallen, le développement initial ne représente qu’un cinquième des coûts d’une application sur cinq ans.
• Modélisez trois à cinq ans et cherchez le point de bascule, les deux options sur un horizon de durée identique.
• Avant de construire quoi que ce soit, réalisez un audit de licences et une consolidation. Si le problème se règle pour un dixième du prix, le sur-mesure est une mauvaise réponse.
• Possédez le processus qui vous différencie et achetez ce qui relève de la commodité. L’architecture hybride est souvent un compromis plus raisonnable que les deux extrêmes.
• Le risque d’un projet informatique se loge dans la queue de distribution, pas dans la moyenne. Construisez par étapes courtes, utiles chacune séparément.