Un SaaS convient lorsque ses parcours couvrent votre besoin avec des adaptations acceptables. Le sur-mesure devient intéressant lorsque vos règles, vos échanges de données ou vos contraintes d’exploitation sont déterminants. Le choix se fait sur un parcours réel et sur le coût de fonctionnement complet, pas sur une préférence technique.
Les repères pour décider.
- Tester les exceptions métier dans une démonstration du SaaS.
- Comparer configuration, intégration et développement avec le même périmètre.
- Prévoir l’exploitation, la sortie et la reprise des données dès la décision.
Commencer par un parcours, pas par une liste de fonctionnalités.
Choisissez une opération que votre équipe réalise souvent : traiter une demande, préparer une intervention ou valider un dossier. Décrivez son début, son résultat, les personnes impliquées et les exceptions. Un catalogue de fonctionnalités peut donner l’impression que deux solutions se valent alors que leur utilisation quotidienne diffère nettement.
Voici un exemple illustratif : un dossier doit être validé par deux personnes seulement au-delà d’un certain montant. Après validation, une modification doit rouvrir le contrôle. Un outil peut afficher des statuts et des approbations sans savoir exprimer cette règle. C’est ce scénario, avec une modification réelle, qu’il faut montrer en démonstration.
Une grille pour comparer les deux options.
Les tendances ci-dessous servent à orienter les questions. Un SaaS extensible peut couvrir des règles complexes ; un développement mal cadré peut créer une dépendance forte. Vérifiez les capacités du produit, les modalités contractuelles et l’organisation qui exploitera la solution.
Faites défiler le tableau horizontalement pour lire toutes les colonnes.
| Critère | SaaS à examiner | Sur-mesure à examiner |
|---|---|---|
| Parcours métier | Adéquation des fonctions et possibilités de configuration. | Règles à concevoir, tester et faire évoluer. |
| Intégrations | API disponibles, quotas, droits et coût des connecteurs. | Connecteurs à construire et comportement sur erreur. |
| Données | Formats d’export, historique récupérable et modalités de sortie. | Modèle de données, migration et procédures de sauvegarde. |
| Évolution | Feuille de route de l’éditeur et limites des extensions. | Budget, compétences et organisation pour maintenir le code. |
| Coût complet | Abonnements, paramétrage, intégrations et interventions manuelles restantes. | Conception, réalisation, infrastructure, maintenance et évolutions. |
Identifier ce qui doit réellement être spécifique.
Toutes les étapes d’un processus ne constituent pas un avantage à développer vous-même. L’authentification, l’envoi d’emails ou la facturation peuvent s’appuyer sur des services existants. Le besoin spécifique se trouve souvent dans une règle d’affectation, une chaîne de validation ou la coordination de plusieurs outils.
Séparez les exigences indispensables des habitudes que l’équipe accepterait de changer. Pour chaque exigence, décrivez la conséquence d’un écart. Une préférence d’écran et une impossibilité de traiter un dossier n’ont pas le même poids. Cette distinction évite de développer une application uniquement pour reproduire une interface connue.
- Quelle règle ne peut pas être modifiée sans perturber l’activité ?
- Quelle adaptation demande seulement une prise en main ?
- Quelle étape relève déjà d’un logiciel spécialisé ?
- Quel contournement devra encore être réalisé à la main ?
Comparer les coûts avec les mêmes hypothèses.
Le prix d’un abonnement et le devis d’un développement ne couvrent pas nécessairement le même travail. Comparez un périmètre commun : utilisateurs, environnements, reprise de données, intégrations, accompagnement et exploitation. Décrivez ensuite comment ces éléments évolueraient si le volume ou l’équipe changeait.
Le temps passé à maintenir les contournements mérite d’être mesuré. Une exportation manuelle, une ressaisie ou une vérification systématique représente du travail réel. Cela ne devient pas automatiquement une économie financière après développement : l’équipe peut employer le temps libéré à d’autres tâches. Distinguez temps disponible, dépenses évitées et nouvelles dépenses.
Prévoir la sortie et la continuité de service.
Demandez comment récupérer les données, les pièces jointes et l’historique. Un fichier d’export ne suffit pas si les relations entre les dossiers disparaissent ou si les documents doivent être téléchargés un par un. Testez une extraction et vérifiez qu’elle permet une reprise utilisable.
Pour le sur-mesure, clarifiez les droits sur le code et les livrables dans le contrat, l’accès au dépôt, les comptes d’hébergement, la documentation et le transfert. La possession d’un dépôt ne remplace pas une procédure de déploiement et une personne capable de l’exécuter. La continuité se prépare avec des responsabilités explicites.
Une troisième voie : conserver le SaaS et construire la liaison.
Votre outil principal peut rester pertinent alors que les échanges autour de lui sont fragiles. Une intégration API ou un portail métier peut réduire les doubles saisies sans recréer toutes ses fonctions. Cette option doit être comparée au remplacement complet.
La bonne décision est parfois progressive : tester une configuration, réaliser une connexion sur un flux, puis développer le parcours réellement spécifique. Fixez ce que le test doit démontrer et les conditions qui conduiraient à retenir une autre option. Vous obtenez une décision documentée plutôt qu’une architecture choisie trop tôt.