Logiciel sur mesure ou SaaS : comment décider sans surinvestir ?

Partir du processus, jamais du catalogue

Décrivez trois parcours réels avec utilisateur, déclencheur, données, règle, exception et résultat. Un besoin formulé comme « il nous faut un CRM » enferme trop tôt la décision. Écrivez plutôt ce que l’équipe doit accomplir, ce qui ralentit aujourd’hui et la preuve qu’un nouveau fonctionnement serait meilleur.

Séparez le cœur métier des fonctions génériques. Comptabilité, paie ou messagerie ont souvent intérêt à rester dans des solutions éprouvées. Un calcul, une validation ou un parcours propre à votre avantage concurrentiel peut justifier une adaptation plus profonde. Le sur-mesure n’est pas une récompense esthétique : c’est une réponse à un écart opérationnel mesurable.

Mesurer l’adéquation sans chercher la perfection

Testez chaque solution sur des situations représentatives, y compris les exceptions. Notez ce qui fonctionne nativement, ce qui se configure, ce qui exige une intégration et ce qui reste impossible. Un taux de couverture élevé sur les opérations fréquentes peut être préférable à une solution parfaite mais longue à maintenir.

Évaluez aussi le coût humain des contournements : double saisie, export, vérification, formation et correction. Ne transformez pas chaque préférence en exigence. Une organisation peut parfois simplifier un processus plutôt que financer sa reproduction exacte dans un logiciel.

Calculer un coût total sur trente-six mois

Pour un SaaS, additionnez licences, utilisateurs, modules, intégration, paramétrage, formation, support et éventuelle hausse liée au volume. Pour le sur-mesure, additionnez cadrage, conception, développement, reprise, hébergement, sécurité, maintenance, support et évolutions. Dans les deux cas, ajoutez migration de sortie et temps interne.

Le prix initial seul favorise artificiellement le SaaS ; oublier maintenance et évolution favorise artificiellement le sur-mesure. Calculez trois scénarios et indiquez la source de chaque hypothèse. Une dépense future inconnue reçoit une plage, pas un zéro rassurant.

Évaluer données, sécurité et responsabilités

Cartographiez les données, leur sensibilité, leur localisation, les accès et les sous-traitants. Le contrat doit préciser assistance, incidents, suppression, export et fin de service. La CNIL rappelle que le recours à un sous-traitant n’efface pas les responsabilités du responsable de traitement.

Le sur-mesure n’est pas automatiquement plus sécurisé : sa qualité dépend de l’architecture, des pratiques, des tests, des mises à jour et de l’exploitation. Un SaaS reconnu n’est pas automatiquement adapté non plus. Exigez des preuves correspondant au risque réel, pas un vocabulaire commercial.

Tester la réversibilité avant de signer

Demandez un export sur un échantillon : formats, relations, pièces jointes, historiques et identifiants. Documentez qui possède le code, les données, les configurations et la documentation. Une promesse d’export sans format, délai ni test n’est pas une stratégie de sortie.

Pour le sur-mesure, vérifiez dépôt de code, accès, documentation, droits sur les composants et procédure de reprise par un tiers. Pour le SaaS, vérifiez préavis, suppression, API, limites et coûts d’extraction. La réversibilité doit être testable avant que la dépendance ne devienne critique.

Choisir parmi cinq options, pas deux

La décision peut être : SaaS standard, SaaS configuré, assemblage avec automatisations, module spécifique connecté ou produit sur mesure. Cette graduation évite le faux choix entre abonnement immédiat et développement complet. Attribuez chaque processus à l’option la moins complexe qui satisfait ses exigences essentielles.

Une architecture hybride exige toutefois une gouvernance : source de vérité, synchronisations, erreurs, responsabilités et surveillance. Ajouter plusieurs outils sans concevoir leurs échanges recrée les doubles saisies que le projet voulait supprimer.

• Standard pour le générique
• Configuration avant développement
• Intégration avec gestion des erreurs
• Sur-mesure pour le différenciant
• Une source de vérité par donnée

Scénario détaillé : société d’interventions

Entrées fictives : douze techniciens, un logiciel de facturation satisfaisant, un planning générique et des comptes rendus ressaisis. Le processus différenciant concerne l’affectation selon compétences, pièces et urgence. Raisonnement : remplacer facturation et paie créerait du risque sans valeur ; un module métier connecté au planning et à la facturation cible la rupture réelle.

Résultat de décision : conserver les SaaS génériques, prototyper le module d’affectation et tester une synchronisation sur un périmètre. Limites : l’intégration dépend des API, contrats et qualité des données. Si le SaaS de planning permet déjà la règle par configuration, le développement doit être abandonné.

Organiser un pilote et une décision

Sélectionnez un parcours complet et quelques utilisateurs représentatifs. Mesurez temps, erreurs, contournements et satisfaction avant le pilote, puis après. Incluez les cas difficiles plutôt qu’une démonstration idéale. Une fonction qui marche en présentation mais échoue sur les exceptions n’est pas prête.

Décidez sur des critères écrits : couverture, temps, qualité, sécurité, adoption, coût et sortie. Documentez ce qui reste manuel et pourquoi. Si le pilote est concluant, étendez progressivement ; sinon, corrigez le processus, changez d’option ou arrêtez sans transformer le coût déjà engagé en justification.

Prévoyez enfin la conduite du changement : référents, formation, documentation, assistance et période de double fonctionnement strictement limitée. Mesurez l’usage réel plutôt que le nombre de comptes créés. Un outil techniquement réussi mais ignoré par les équipes ne produit pas la valeur attendue ; l’adoption fait donc partie de la décision d’investissement dès le cadrage.