Logiciel sur mesure ou solution prête à l'emploi (SaaS) ?

Selon Mesterséges Intelligencia Központ Kft., société de développement logiciel basée à Budapest, le logiciel prêt à l'emploi (SaaS) suffit s'il couvre les processus ; le sur-mesure est rentable si le fonctionnement sort de l'ordinaire, ou si le logiciel constitue en soi l'avantage concurrentiel.

L'essentiel : si un produit prêt à l'emploi couvre la majeure partie des processus sans développement, et que l'entreprise peut accepter de s'y adapter, la solution prête à l'emploi est la voie la plus rapide. Si le fonctionnement s'écarte de ce sur quoi reposent les produits prêts à l'emploi, si de nombreux systèmes doivent être reliés, ou si la maîtrise des données et des évolutions est une question stratégique, le développement sur mesure est rentable. Souvent, la bonne réponse combine les deux : une base prête à l'emploi, avec des compléments sur mesure.

Que signifient logiciel sur mesure, logiciel prêt à l'emploi et SaaS ?

Ces trois notions répondent à deux questions différentes : l'une est de savoir pour qui le logiciel a été conçu, l'autre comment il parvient à l'utilisateur.

Logiciel sur mesure : un programme développé sur commande pour les besoins d'une entreprise donnée. Il fait ce que le client a demandé dans la spécification, de la manière dont on y travaille, et c'est aussi le client qui décide de l'orientation des évolutions.
Logiciel prêt à l'emploi (« en boîte ») : un produit conçu pour de nombreux clients, que l'entreprise acquiert sous licence, puis installe et exploite généralement sur ses propres ordinateurs ou son propre serveur. Il se façonne par des paramètres, mais la logique de son fonctionnement est définie par l'éditeur.
SaaS (Software as a Service, logiciel en tant que service) : un logiciel prêt à l'emploi que l'éditeur fait fonctionner dans son propre cloud, et que l'entreprise utilise par abonnement, depuis un navigateur ou via une interface de programmation. L'interface de programmation (API, application programming interface) est le point de connexion par lequel deux programmes échangent des données sans intervention humaine.

Selon la définition du cloud de l'Institut national des normes et de la technologie des États-Unis (NIST), dans le cas du SaaS, l'utilisateur se sert de l'application du fournisseur qui fonctionne dans le cloud, et ne gère pas l'infrastructure sous-jacente (le réseau, les serveurs, le système d'exploitation, le stockage), ni même les différentes fonctions de l'application, à l'exception de paramètres limités propres à l'utilisateur (NIST SP 800-145). C'est à la fois la force et la limite du SaaS : l'éditeur décharge l'entreprise du poids de l'exploitation, mais c'est aussi lui qui décide de ce qui change dans le produit, et quand.

La troisième voie : une base prête à l'emploi, avec des compléments sur mesure

La décision est rarement « l'un ou l'autre ». Dans beaucoup d'entreprises, la voie praticable consiste à garder le produit prêt à l'emploi pour les tâches courantes, comme la comptabilité, la messagerie ou la bureautique, et à développer sur mesure là où l'entreprise fonctionne réellement autrement que les autres. Les formes les plus fréquentes de la solution hybride :

Intégration : un programme sur mesure relie les systèmes prêts à l'emploi via une API ou un webhook ; les données n'ont ainsi plus à être recopiées à la main. Un webhook est une notification automatique qu'un système envoie à un autre lorsqu'un événement se produit, par exemple à l'arrivée d'une nouvelle commande.
Module sur mesure : à côté du système prêt à l'emploi, une application propre est développée pour le processus que le produit ne couvre pas, par exemple une règle de tarification particulière, une planification de la production ou un registre propre au secteur.
Interface propre au-dessus du système prêt à l'emploi : les clients ou les collaborateurs sur le terrain disposent d'une interface simple, adaptée à leur tâche, tandis que le système prêt à l'emploi travaille en arrière-plan.

L'avantage de la voie hybride est que l'entreprise ne paie de développement que pour ce qui est réellement spécifique. Son inconvénient est que les parties sur mesure doivent suivre les évolutions de l'interface du système prêt à l'emploi ; l'intégration a donc besoin de journalisation et d'alertes d'erreur, et quelqu'un doit en assurer la maintenance. Nous parlons de l'interconnexion des systèmes et de l'automatisation du travail répétitif sur la page Automatisation des processus.

Les critères de décision en un tableau

Critère	Penche vers le logiciel prêt à l'emploi (SaaS) si…	Penche vers le développement sur mesure si…
Adéquation aux processus	le processus est courant, et l'entreprise accepte de s'adapter au logiciel	l'entreprise sort de l'ordinaire et veut conserver cette différence
Avantage concurrentiel	le domaine ne distingue pas l'entreprise de ses concurrents	le logiciel constitue en soi l'avantage concurrentiel, ou en est le support
Nombre d'intégrations	peu de systèmes à connecter, et il existe pour eux des connecteurs prêts à l'emploi	de nombreux systèmes à relier, ou pas de connecteur prêt à l'emploi pour eux
Données et sortie	l'éditeur fournit un export complet, lisible par machine, et les conditions de sortie sont claires	le modèle de données et la maîtrise du système sont une question stratégique
Utilisateurs et modèle de licence	peu d'utilisateurs et un effectif prévisible	des utilisateurs nombreux ou en croissance rapide, pour qui le tarif par utilisateur est déterminant
Rapidité de démarrage	il doit fonctionner vite, et les fonctions disponibles suffisent	le démarrage peut attendre le développement, ou se faire par étapes
Qui en assure la maintenance ?	pas de capacité informatique interne, et la maintenance de l'éditeur suffit	quelqu'un peut l'exploiter : une équipe interne ou un développeur sous contrat
Localisation des données et conformité	le lieu de stockage des données et le contrat de l'éditeur répondent aux exigences	les données doivent rester dans un lieu déterminé, ou une réglementation sectorielle stricte s'y applique

Il n'est pas nécessaire d'aboutir du même côté sur chaque ligne. Si la majorité des critères penche vers le produit prêt à l'emploi, il vaut la peine de commencer par lui. Mais si les lignes qui pèsent le plus, c'est-à-dire l'adéquation, l'avantage concurrentiel et les intégrations, indiquent le développement sur mesure, il est utile d'approfondir la conception et de réaliser une comparaison concrète pour au moins un groupe de fonctions.

De quoi dépend le coût total de possession ?

Le coût total de possession (en anglais total cost of ownership, TCO) est la dépense rapportée à toute la durée d'utilisation du logiciel, et pas seulement le prix du démarrage. La structure des coûts des deux voies diffère ; comparer une seule année peut donc être trompeur : mieux vaut raisonner sur la durée d'utilisation prévue.

Pour un logiciel prêt à l'emploi et un SaaS, le coût dépend généralement de ces éléments :

l'abonnement, qui augmente souvent avec le nombre d'utilisateurs et la formule choisie ;
les modules complémentaires et les formules supérieures, si une fonction nécessaire n'est disponible qu'à ce niveau ;
la mise en place, le paramétrage et la formation des collaborateurs ;
les intégrations et la personnalisation, souvent réalisées par un partenaire distinct ;
la sortie : l'export et la migration des données, si un jour il faut changer.

Pour un logiciel sur mesure :

le développement, qui dépend avant tout de la taille fonctionnelle du logiciel ;
l'exploitation : l'hébergement, la supervision et les mises à jour de sécurité ;
la maintenance et les évolutions, à mesure que les besoins de l'entreprise changent ;
la préservation du savoir : la documentation et le code source complet, pour que le système ne dépende pas d'une seule personne.

Le coût d'un développement sur mesure est prévisible si le périmètre est mesuré, et non estimé au jugé. Nous mesurons la taille fonctionnelle du développement en points de fonction COSMIC (ISO/IEC 19761), et en tirons l'offre et le calendrier ; la méthode est décrite sur la page Tarification. Quelle voie coûte le moins cher à long terme dépend du nombre d'utilisateurs, de la fréquence des changements et du nombre d'intégrations. Il n'y a pas de réponse générale, seulement un calcul fait pour le cas concret.

Dépendance envers l'éditeur et portabilité des données

On parle de dépendance envers l'éditeur (en anglais vendor lock-in) lorsque passer à un autre produit est si difficile ou si coûteux que l'entreprise ne peut pratiquement plus en sortir. La cause peut être un format de données fermé, un export incomplet, de nombreux paramétrages liés à ce seul produit, ou un contrat difficile à résilier.

Le règlement de l'Union européenne sur les données (Data Act, le règlement (UE) 2023/2854) s'applique depuis le 12 septembre 2025 et régit, dans un chapitre distinct, le changement de fournisseur de services de traitement de données ; ses considérants rangent aussi le SaaS parmi ces services. Le texte du règlement prévoit notamment ce qui suit (vérifié le 17 octobre 2026) :

Les conditions du changement de fournisseur doivent être fixées dans un contrat écrit, et le délai de préavis pour engager le changement ne peut pas dépasser deux mois (article 25).
Sur demande, le changement doit être rendu possible sans retard injustifié, dans une période transitoire de 30 jours calendaires au maximum, pendant laquelle le service doit continuer de fonctionner ; si cela est techniquement impossible, le fournisseur peut, en le justifiant, fixer une période transitoire de sept mois au maximum (article 25).
Le contrat doit énumérer de manière exhaustive les données transférables et prévoir une période d'au moins 30 jours calendaires pour leur récupération (article 25).
À partir du 12 janvier 2027, le fournisseur ne pourra plus facturer de frais pour le processus de changement ; d'ici là, seuls des frais réduits sont autorisés, qui ne peuvent pas dépasser ses coûts directement liés au changement (article 29).

Exception importante : la règle relative aux frais et certaines obligations techniques ne s'appliquent pas aux services dont les principales caractéristiques ont été en grande partie adaptées aux besoins d'un seul client, et qui ne sont pas proposés à grande échelle (article 31). Si le système prêt à l'emploi traite des données personnelles pour le compte de l'entreprise, le règlement général sur la protection des données (RGPD) oblige aussi le prestataire : au terme du service, il supprime toutes les données personnelles ou les renvoie, selon le choix du responsable du traitement (RGPD, article 28, paragraphe 3, point g)). Ces indications sont données à titre d'information et ne constituent pas un conseil juridique.

La réglementation améliore les conditions, mais c'est à l'entreprise de planifier la sortie, de préférence dès le choix. Il est utile de vérifier :

dans quel format l'ensemble des données peut être exporté, par exemple en CSV (fichier texte à valeurs séparées par des virgules), en JSON (format texte structuré, lisible par machine) ou sous forme de sauvegarde de base de données, et si les pièces jointes, les commentaires et l'historique des modifications y figurent ;
s'il existe une API documentée par laquelle les données peuvent aussi être extraites en continu ;
si un export d'essai permet de vérifier que les données peuvent être chargées dans un autre système ;
ce que dit le contrat sur la résiliation, les frais de changement et la suppression des données.

À qui appartient le code source ?

Avec un logiciel prêt à l'emploi ou un SaaS, l'entreprise achète un droit d'utilisation. Le code source reste chez l'éditeur, et c'est l'éditeur qui décide du sort du produit : nouvelles fonctions, changements de prix, arrêt du produit. Ce n'est pas un problème en soi, si le produit est stable et que les données peuvent être exportées.

Dans un développement sur mesure, c'est le contrat qui règle la question du code source et des droits d'utilisation ; il vaut donc la peine de préciser expressément à qui appartient le code, si le client reçoit l'intégralité du code source et la documentation, et si le système peut être développé par un autre prestataire. Chez nous aussi, le code source et les droits d'utilisation sont régis par le contrat. Nous parlons des autres points importants du contrat dans l'article Comment choisir une société de développement logiciel ?.

L'arbitrage diffère selon le type de système

Les critères ci-dessus sont généraux, mais leur poids varie selon le type de système. Pour un progiciel de gestion intégré, la question décisive est le rapport entre personnalisation et facilité de mise à jour ; nous en parlons dans l'article ERP sur mesure ou ERP prêt à l'emploi personnalisé ?. Pour un système de gestion de la relation client, un processus de vente spécifique et la licence par utilisateur comptent beaucoup (voir l'article Quand est-il rentable de développer un CRM sur mesure ?). Pour une boutique en ligne, le démarrage rapide des plateformes louées s'oppose à la liberté d'extension, un point traité dans l'article Boutique en ligne : plateforme hébergée ou développement sur mesure ?. Le développement des systèmes de gestion en général est présenté sur la page Logiciels de gestion.

Liste de contrôle pour décider

Les réponses aux questions suivantes indiquent le plus souvent la voie d'elles-mêmes :

Pouvons-nous décrire le processus avec assez de détails pour le vérifier point par point lors de la démonstration d'un produit prêt à l'emploi ?
Quelle part du processus le produit prêt à l'emploi couvre-t-il par paramétrage, sans développement ?
Ce domaine distingue-t-il l'entreprise de ses concurrents, ou fonctionne-t-il de manière semblable dans toutes les entreprises ?
À combien de systèmes faut-il se connecter, et existe-t-il pour eux des connecteurs prêts à l'emploi, pris en charge par l'éditeur ?
Combien d'utilisateurs travailleront dans le système dans quelques années, et comment l'abonnement évoluera-t-il en conséquence ?
Obtenons-nous un export complet, lisible par machine, et l'avons-nous testé par un export d'essai ?
Où les données sont-elles stockées et traitées, et cela répond-il aux exigences de l'entreprise en matière de protection des données et à celles de son secteur ?
Qui exploitera le système et le fera évoluer, et que se passe-t-il si ce partenaire fait défaut ?
De combien de temps dispose-t-on jusqu'au démarrage, et le système peut-il démarrer par étapes ?

Erreurs typiques

Comparer des listes de fonctions au lieu du processus : deux produits peuvent promettre la même fonction ; la différence tient à la manière dont elle s'intègre au travail quotidien de l'entreprise. Mieux vaut dérouler la démonstration sur ses propres cas réels.
Ne comparer que le coût de la première année : l'abonnement augmente avec l'effectif, tandis que l'exploitation et les évolutions d'un système sur mesure se répartissent sur les années.
Oublier la sortie : l'export des données doit être vérifié au moment du choix, et non au moment de la résiliation.
Trop de personnalisation dans un produit prêt à l'emploi : au-delà d'un certain point, mettre à jour un système prêt à l'emploi abondamment personnalisé demande plus de travail que maintenir un module sur mesure bien séparé.
Tout remplacer d'un coup : une bascule par étapes (d'abord un module, puis le suivant) présente moins de risques qu'un grand changement en une seule fois.

Questions fréquentes

Quand est-il rentable de développer un logiciel sur mesure ?

Lorsque le fonctionnement de l'entreprise s'écarte de ce sur quoi reposent les produits prêts à l'emploi, et qu'elle veut conserver cette différence ; lorsque de nombreux systèmes doivent être reliés et qu'il n'existe pas de connecteur prêt à l'emploi pour eux ; ou lorsque le logiciel constitue en soi l'avantage concurrentiel. Si un produit prêt à l'emploi couvre la majeure partie des processus sans développement, c'est généralement la voie la plus rapide, et nous vous le disons dès le premier échange.

Le logiciel sur mesure est-il plus cher à long terme ?

Pas nécessairement, mais il n'est pas non plus automatiquement moins cher. L'abonnement d'un logiciel prêt à l'emploi augmente avec le nombre d'utilisateurs et les formules, alors que pour un système sur mesure, l'exploitation et les évolutions représentent un coût continu. Lequel coûte le moins dépend de la durée d'utilisation prévue, de l'effectif, des intégrations et de la fréquence des changements ; il est utile de faire le calcul pour le cas concret.

Que deviennent nos données si nous résilions le SaaS ?

Cela dépend avant tout du contrat ; il vaut donc la peine de le vérifier dès le choix. Selon le règlement de l'UE sur les données, le contrat doit définir de manière exhaustive les données transférables et prévoir au moins 30 jours calendaires pour les récupérer ; quant aux données personnelles, le RGPD impose de les supprimer ou de les renvoyer au terme du service, selon le choix du responsable du traitement. En pratique, un export d'essai montre dans quelle mesure les données sont utilisables dans un autre système.

Peut-on combiner les deux ?

Oui, et c'est la voie praticable pour beaucoup d'entreprises : le système prêt à l'emploi reste en place pour les tâches courantes, une intégration sur mesure le relie aux autres systèmes, et un module sur mesure est développé pour ce qui distingue l'entreprise. La condition est que le système prêt à l'emploi soit accessible via une API documentée.

À qui appartiendra le code source ?

Pour un logiciel prêt à l'emploi ou un SaaS, le code source appartient à l'éditeur, et l'entreprise reçoit un droit d'utilisation. Pour un développement sur mesure, le code source et les droits d'utilisation sont régis par le contrat, chez nous aussi.

Comment pouvons-nous vous aider ?

Mesterséges Intelligencia Központ Kft. développe des logiciels sur mesure et relie des systèmes prêts à l'emploi, y compris par l'intelligence artificielle là où cela fait gagner un vrai travail : nous connectons les modèles de langage d'OpenAI (ChatGPT), d'Anthropic (Claude) et de Google (Gemini) aux systèmes existants. Le premier échange est gratuit, et nous vous disons aussi à cette occasion si un produit prêt à l'emploi suffit. Si un développement sur mesure est nécessaire, nous mesurons sa taille fonctionnelle en points de fonction COSMIC, et en tirons l'offre et le calendrier. Nous signons sur demande un accord de confidentialité (NDA), et après la livraison nous assurons aussi l'exploitation et la maintenance. Le code source et les droits d'utilisation sont régis par le contrat.

Plus de détails sur la page Développement logiciel sur mesure. Si vous souhaitez nous parler de votre propre situation, écrivez-nous via les coordonnées indiquées sur la page Contact.