Pour une PME, un SaaS est le meilleur point de départ quand le besoin est standard, que l’équipe peut l’adopter et que les données restent récupérables. Le sur-mesure devient pertinent lorsqu’une règle propre à l’activité crée de la valeur ou que les contournements d’un outil standard coûtent durablement cher. Entre les deux, paramétrer, intégrer ou développer une brique ciblée est souvent le choix le plus rationnel.
Article vérifié le 8 septembre 2026. Les critères proposés servent à cadrer une décision ; ils ne remplacent ni l’étude d’un contrat, ni une analyse de sécurité ou de conformité.
La bonne question porte sur un processus, pas sur toute la PME
Une entreprise n’a pas à choisir un camp « tout SaaS » ou « tout sur-mesure ». Elle doit décider comment équiper un processus délimité : établir un devis, planifier une intervention, valider une commande ou ouvrir un portail à ses clients.
Ce périmètre évite de reconstruire des fonctions standard déjà bien couvertes, mais aussi de forcer une règle métier différenciante dans un outil qui oblige l’équipe à ressaisir ou corriger ailleurs. Une phrase observable, comme « transformer une demande validée en commande sans ressaisie », permet ensuite de comparer les solutions sur trois cas réels, dont une exception.
Que recouvrent vraiment SaaS, paramétrage, intégration et sur-mesure ?
Un SaaS, ou logiciel fourni comme un service, permet d’utiliser l’application d’un éditeur sans administrer son infrastructure. Le client agit surtout dans les possibilités de configuration prévues par le produit, comme le résume la définition du NIST.
Dans une PME, quatre trajectoires méritent d’être comparées :
| Trajectoire | Ce que vous achetez ou construisez | Bonne candidate lorsque… | Effort qui reste chez vous |
|---|---|---|---|
| SaaS standard | Un produit utilisé presque tel quel | le processus est courant et vos cas réels passent sans blocage | choix, configuration légère, formation, administration et contrôle |
| SaaS paramétré | Le produit, ses règles, modèles et automatisations | l’écart se résout avec des réglages documentés et réversibles | gouvernance des réglages, tests après mises à jour, accompagnement |
| Brique spécifique intégrée | Un module métier relié à des outils existants | une étape vous distingue, tandis que CRM, facturation ou identité restent standard | produit, intégrations, exploitation et maintenance du module |
| Logiciel spécifique plus complet | Une application et son socle conçus pour votre usage | le processus entier est singulier, critique et durable | pilotage produit, hébergement, sécurité, support, maintenance et sortie |
Le choix hybride n’est pas un compromis flou. Il trace une frontière explicite entre ce que le marché résout déjà et ce que l’entreprise a intérêt à maîtriser.
Première porte : quelles contraintes éliminent une option ?
Avant de noter les solutions, vérifiez les exigences non négociables. Une option qui échoue sur l’une d’elles ne doit pas gagner grâce à un bon total ailleurs.
Le scénario métier tient-il sans contournement critique ?
Demandez une démonstration avec vos données représentatives. Faites exécuter le cas nominal, puis une exception : commande modifiée après validation, technicien remplacé en urgence, avoir partiel ou droit d’accès temporaire. Notez les ressaisies, exports et validations réalisées hors de l’outil.
Une fonction présente dans la brochure ne prouve pas que le parcours fonctionne. France Num recommande aussi de confronter l’offre au besoin réel et de faire dérouler ses propres cas.
Les données et les connexions nécessaires sont-elles accessibles ?
Vérifiez les données exportables, leur format, les pièces jointes, l’historique, les identifiants et les relations entre objets. Pour une intégration, demandez aussi quelles actions l’API autorise, ses limites, la gestion des erreurs et la manière de rejouer une synchronisation interrompue.
Un bouton « Export CSV » ne suffit pas si les statuts, documents ou liens entre clients, commandes et paiements disparaissent. Les articles 23 à 25 du règlement européen sur les données encadrent depuis 2025 certains aspects du changement de services, mais une obligation contractuelle ne transforme pas automatiquement un export en migration opérationnelle.
La sécurité et les responsabilités correspondent-elles au risque ?
Le sur-mesure n’est pas sûr par nature, et le SaaS ne transfère pas toute la responsabilité à l’éditeur. Pour des données personnelles, la CNIL recommande d’inventorier les services SaaS, de formaliser les responsabilités et d’examiner sauvegarde, chiffrement, localisation et continuité dans sa fiche Sécurité : Cloud, informatique en nuage.
Deuxième porte : l’équipe peut-elle accomplir son travail ?
Faites tester le finaliste par les profils qui exécutent et contrôlent le processus, pas seulement par la direction ou l’équipe informatique.
Pendant l’essai, observez quatre éléments :
- la réussite du parcours sans assistance du vendeur ;
- le temps et les informations nécessaires pour corriger une erreur ;
- les fichiers, messages ou notes conservés à côté de l’outil ;
- la capacité d’un responsable à comprendre l’état du travail.
Fixez vos critères avant l’essai à partir de la situation de départ. Une application quotidienne pour des techniciens et un outil mensuel de clôture ne se jugent pas de la même façon.
Comment comparer le coût complet sans inventer un seuil ?
Comparer le prix mensuel d’un SaaS au devis initial d’un développement fausse la décision. Choisissez un horizon cohérent avec votre engagement, puis appliquez la même structure aux quatre trajectoires.
Pour un SaaS, additionnez : mise en place, abonnement selon les utilisateurs et modules, paramétrage, migration, intégrations, formation, administration interne, contournements, assistance et sortie.
Pour un logiciel spécifique, additionnez : cadrage, conception, développement, reprise de données, hébergement, supervision, sécurité, support, maintenance, évolutions, temps de pilotage interne et sortie vers un autre mainteneur ou outil.
Mesurez le temps de ressaisie, de rapprochement et de correction sur quelques semaines. Ne transformez pas chaque minute en économie promise : certaines tâches deviendront des contrôles utiles.
| Question à documenter | Preuve attendue | Effet sur la décision |
|---|---|---|
| Que paie-t-on pendant l’horizon ? | tarifs, devis, temps interne, hypothèses d’usage | compare des périmètres complets, pas abonnement contre développement |
| Quel travail reste hors de l’outil ? | observation d’un cycle réel, erreurs et doubles saisies | révèle le coût opérationnel d’un mauvais ajustement |
| Quelle évolution dépend d’un tiers ? | contrat, feuille de route, documentation, disponibilité API | rend visible la dépendance à l’éditeur ou au mainteneur |
| Comment quitte-t-on la solution ? | export test, format, délai, pièces jointes, aide à la migration | chiffre la réversibilité au lieu de la traiter comme une clause abstraite |
| Qui porte l’outil après le lancement ? | rôles, disponibilité, budget et procédure d’incident | vérifie que l’entreprise peut réellement exploiter le choix |
Exemple rempli : une PME fabrique des équipements sur commande
Cet exemple est fictif. Une PME de 22 personnes vend des équipements configurés selon le site du client. Elle utilise déjà un CRM et un logiciel de comptabilité en SaaS. Les commerciaux préparent pourtant les configurations et les prix dans plusieurs tableurs, puis un responsable vérifie manuellement les incompatibilités avant la commande.
Le besoin est formulé ainsi : produire une configuration techniquement valide, faire approuver une dérogation et transmettre le devis accepté sans ressaisie. Les contraintes sont les suivantes : conserver le CRM et la comptabilité, tracer la version des règles utilisée, pouvoir expliquer un refus et ne pas bloquer les ventes pendant la transition.
L’équipe compare trois options sur vingt dossiers représentatifs :
| Option testée | Observation sur les cas | Décision dans cet exemple |
|---|---|---|
| Remplacer CRM et gestion par un ERP | couvre les fonctions standard mais impose une migration très large | écarté : trop de changement pour le seul processus à corriger |
| Paramétrer un module du CRM | traite les cas simples, mais les incompatibilités restent en tableur | écarté si ces règles restent opaques ou impossibles à tester |
| Construire un configurateur relié | concentre les règles propres au produit et renvoie le résultat au CRM | retenu sous réserve d’un prototype sur les dossiers les plus difficiles |
La décision n’est pas « le sur-mesure gagne ». La PME conserve deux SaaS pour des fonctions standard et n’envisage une brique spécifique que pour les règles qui créent les ressaisies et les erreurs. Elle accepte en échange de financer la maintenance de ce module, de nommer un responsable produit et de documenter les interfaces.
Si un SaaS vertical exécute les vingt dossiers, exporte les résultats et respecte les contraintes de transition, il redevient le premier choix. La méthode laisse donc le résultat ouvert à la preuve.
Les erreurs qui rendent la comparaison trompeuse
Décider depuis une démonstration commerciale. Faites manipuler vos cas et leurs exceptions par les futurs utilisateurs.
Considérer les tableurs parallèles comme gratuits. Une solution temporaire peut être valable, mais sa ressaisie et ses erreurs doivent apparaître dans la comparaison.
Confondre propriété du code et indépendance. Sans documentation, accès, tests et capacité de maintenance, le code reste difficile à reprendre.
Personnaliser un SaaS sans gouvernance. Réglages et automatisations sans propriétaire créent une dépendance que le contrat ne décrit pas.
Reconstruire les fonctions standard par principe. Chaque fonction spécifique ajoute des tests, de la sécurité, du support et des évolutions à financer.
Que demander avant de signer ou de lancer un développement ?
Préparez un dossier court : processus ciblé, trois cas réels, contraintes éliminatoires, utilisateurs, systèmes à relier, horizon de comparaison et responsable interne. Le modèle de cahier des charges d’application aide à distinguer ce qui est décidé de ce qui doit être proposé.
Demandez ensuite les preuves suivantes :
- une démonstration ou un prototype avec vos cas et vos rôles ;
- la liste des données importables et exportables, avec un fichier d’essai ;
- les limites des intégrations et la gestion des erreurs ;
- les responsabilités de sécurité, sauvegarde, support et continuité ;
- le coût complet sur l’horizon choisi et les hypothèses qui peuvent le faire varier ;
- la procédure de sortie, de suppression et de reprise par un tiers.
Si l’option spécifique porte sur une application, le guide sur le prix d’un développement mobile complète cette comparaison en détaillant les postes souvent absents d’un premier chiffrage.
Ce que Klaapp peut clarifier lors d’un premier échange
Klaapp peut isoler le processus, préparer les scénarios de test et comparer SaaS, paramétrage, intégration et développement spécifique. Le premier échange peut aussi conclure qu’un outil du marché suffit. Si une brique doit être construite, le cadrage d’un produit permet de définir sa frontière, ses intégrations et les responsabilités après le lancement.
Questions fréquentes
Un SaaS est-il toujours moins cher qu’un logiciel sur mesure ?
Non. Le SaaS réduit souvent l’investissement initial, mais son coût complet inclut abonnements, modules, intégrations, administration, formation, contournements et sortie. Le sur-mesure ajoute conception, développement, exploitation et maintenance. Comparez les mêmes usages sur le même horizon.
Un logiciel sur mesure permet-il d’éviter toute dépendance ?
Non. La dépendance se déplace vers le code, l’hébergement, les bibliothèques et les personnes qui maintiennent le produit. Elle se réduit avec des accès complets, une documentation exploitable, des tests, des sauvegardes et une procédure de reprise.
Peut-on commencer avec un SaaS puis développer plus tard ?
Oui, si les données sont exportables et si les intégrations ne ferment pas la sortie. Documentez dès le départ les identifiants, formats, pièces jointes, historiques et règles qui devront être repris.
Le no-code ou le low-code constitue-t-il une troisième voie ?
Ces outils changent la manière de construire, pas les questions de fond. Vérifiez les limites fonctionnelles, la gouvernance des règles, les intégrations, la sécurité, le coût d’usage et la réversibilité comme pour toute autre solution.
Sources
- NIST — Software as a Service (SaaS)
- France Num — Comment choisir le bon logiciel de gestion pour une TPE PME du bâtiment ?
- CNIL — Sécurité : Cloud, informatique en nuage
- EUR-Lex — Règlement (UE) 2023/2854 sur les données
Valentin Merault est cofondateur de Klaapp. Il intervient sur le cadrage, le produit, l’IHM et l’expérience utilisateur. Découvrir le studio Klaapp.