Logiciel sur mesure ou SaaS : comment trancher
Le tableur partagé ne tient plus, l’équipe ressaisit les mêmes informations à trois endroits et le dirigeant se demande s’il faut « faire développer quelque chose ». Avant d’en arriver là, une question mérite d’être posée calmement : le besoin est-il vraiment unique, ou ressemble-t-il à celui de milliers d’autres entreprises ? La réponse oriente presque tout le reste.
Trois familles de solutions
On confond souvent les termes. Voici ce qu’ils recouvrent :
- Le logiciel en ligne par abonnement (SaaS) : l’éditeur héberge l’application, la met à jour et la rend accessible par navigateur ou application mobile. L’entreprise paie un abonnement, généralement par utilisateur ou par volume.
- Le logiciel installé (sous licence) : il est installé sur les postes ou sur un serveur de l’entreprise. Celle-ci gère l’installation, les sauvegardes et parfois les mises à jour.
- Le logiciel sur mesure : il est conçu pour l’entreprise, par un prestataire ou par un développeur salarié, à partir de ses propres règles de fonctionnement.
Entre les deux extrêmes existent des solutions intermédiaires : un logiciel standard paramétré en profondeur, ou des outils assemblés avec des plateformes no-code ou low-code.
Le tableau de comparaison
| Critère | SaaS | Logiciel installé | Sur mesure |
|---|---|---|---|
| Délai de mise en route | Court, parfois immédiat | Court à moyen | Long (conception, développement, tests) |
| Adéquation au besoin | Celle prévue par l’éditeur | Celle prévue par l’éditeur | Aussi fine que le cahier des charges |
| Mises à jour | Gérées par l’éditeur | À la charge de l’entreprise | À prévoir dans un contrat de maintenance |
| Hébergement et sauvegarde | Gérés par l’éditeur | À la charge de l’entreprise | À organiser (prestataire ou hébergeur) |
| Dépendance | Envers l’éditeur et ses évolutions | Envers l’éditeur de la licence | Envers celui qui connaît le code |
| Propriété | Droit d’usage seulement | Droit d’usage (licence) | Possible, si une cession de droits est écrite |
| Coût dans le temps | Récurrent, prévisible | Achat ou licence, puis maintenance | Investissement initial, puis maintenance |
Les signes qu’un logiciel standard suffit
Dans la grande majorité des cas, une TPE-PME trouve son bonheur dans un logiciel existant. C’est le cas quand le besoin porte sur une fonction « classique » : facturation, devis, comptabilité, gestion de la relation client, planning, stock. Ces domaines sont encadrés par des règles communes à toutes les entreprises (mentions de facture, TVA, conservation des pièces) que les éditeurs suivent pour des milliers de clients, ce qui est difficile à égaler seul.
Autres indices favorables au standard :
- l’entreprise peut adapter un peu sa façon de faire sans perdre en efficacité ;
- l’essentiel du besoin est couvert par les fonctions de base, le reste relève du confort ;
- personne en interne n’a le temps de piloter un projet de développement ;
- il faut une solution opérationnelle dans les semaines qui viennent.
Si vous en êtes encore à vous demander s’il faut quitter le tableur, l’article tableur ou CRM détaille les signaux d’alerte.
Les situations où le sur mesure se défend
Le développement spécifique prend son sens quand le logiciel touche au cœur de ce qui distingue l’entreprise : une méthode de calcul de prix propre au métier, un circuit de production particulier, un service client organisé d’une façon que les concurrents n’ont pas. Le forcer dans un outil standard reviendrait à renoncer à cet avantage, ou à multiplier les contournements.
Il peut aussi se justifier quand il faut relier entre eux plusieurs logiciels standards qui ne communiquent pas : un petit outil spécifique sert alors de « colle » entre l’existant, sans tout remplacer. Enfin, certaines activités très spécialisées ne trouvent tout simplement pas d’offre adaptée sur le marché.
Dans tous ces cas, le sur mesure n’est pas un achat ponctuel. Un logiciel vit : il faut le corriger, l’adapter aux évolutions réglementaires, le faire tourner sur un serveur à jour. Ce coût de fonctionnement, souvent sous-estimé, est détaillé dans notre article sur ce qui fait le coût d’un logiciel sur mesure.
Les questions à se poser avant de trancher
Une grille simple permet de clarifier la décision :
- Le besoin est-il partagé par d’autres entreprises de mon secteur ? Si oui, cherchez d’abord ce qui existe.
- Que se passe-t-il si l’outil s’arrête une journée ? Plus l’impact est fort, plus la question de l’hébergement, de la sauvegarde et du niveau de service devient centrale.
- Qui pilotera le projet en interne ? Un projet sur mesure sans interlocuteur disponible côté client dérive presque toujours.
- Qui maintiendra l’outil dans trois ans ? Le prestataire, un salarié, un autre prestataire capable de reprendre le code ?
- Où seront mes données, et pourrai-je les récupérer ? Valable pour les deux options : un SaaS doit prévoir la réversibilité, un sur mesure doit être documenté.
Les risques propres à chaque option
Avec un SaaS, le principal risque est la dépendance : l’éditeur peut modifier ses tarifs, supprimer une fonction, être racheté ou cesser son activité. D’où l’importance de lire les clauses de réversibilité, de propriété des données et de niveau de service, que nous détaillons dans l’article contrat SaaS et réversibilité.
Avec un logiciel sur mesure, les risques sont différents : dépassement de délai, périmètre mal défini, code que personne d’autre ne sait reprendre, absence de documentation. En droit français, un logiciel développé par un prestataire indépendant ne devient pas automatiquement la propriété du client : sans clause de cession de droits écrite et précise, l’entreprise peut se retrouver avec un simple droit d’utilisation. C’est un point à faire vérifier avant de signer.
Une démarche progressive
Rien n’oblige à choisir une fois pour toutes. Beaucoup d’entreprises commencent par un logiciel standard, mesurent ce qui manque réellement à l’usage, puis font développer uniquement les briques manquantes. Cette approche limite le risque : on ne paie un développement que pour ce qui a prouvé son utilité. Elle suppose seulement de choisir dès le départ des outils capables d’échanger leurs données avec d’autres, par export ou par interface de programmation.
Cet article peut contenir des liens partenaires. Ils n'influencent jamais ce que nous écrivons.