Un besoin logiciel commence rarement par un cahier des charges complet. Il commence par une tâche qui prend trop de temps, des validations par e-mail ou un fichier devenu difficile à maintenir. À ce stade, choisir immédiatement entre un SaaS et un développement sur mesure revient à décider de la solution avant d’avoir décrit le travail.
Nous proposons de comparer les options sur un même processus : ses utilisateurs, ses exceptions, ses données et son fonctionnement après livraison. Le sur-mesure doit pouvoir justifier la responsabilité durable qu’il crée. Le SaaS doit pouvoir démontrer que son fonctionnement convient réellement au métier.
Décrire ce qui doit changer pour l’utilisateur
Commencer par un parcours concret. Qui déclenche la demande ? Quelle information manque aujourd’hui ? Qui décide ? Que se passe-t-il lorsque la situation ne correspond pas au cas habituel ? Quelle sortie doit rejoindre un autre système ?
Séparer ensuite les contraintes indispensables des habitudes modifiables. Une règle d’accès ou une exigence de traçabilité peut conditionner le choix. La disposition exacte d’un ancien tableur ne constitue pas nécessairement une obligation. Cette distinction évite de demander à un éditeur de reproduire chaque particularité de l’existant.
Comparer les trois options sur les mêmes critères
| Critère | SaaS | Sur mesure | Combinaison |
|---|---|---|---|
| Processus | Vérifier l’adéquation aux parcours et exceptions réels. | Préciser les règles spécifiques qui justifient la construction. | Délimiter ce qui relève du produit et de l’extension. |
| Données | Tester import, API, export et limites applicables à l’offre envisagée. | Définir interfaces, responsabilité et qualité des données. | Éviter les responsabilités ambiguës entre systèmes. |
| Évolution | Examiner configuration, extensions et dépendance à la roadmap éditeur. | Prévoir budget, compétences et priorisation des changements. | Anticiper l’effet des mises à jour sur les extensions. |
| Exploitation | Clarifier support, droits et responsabilités contractuelles. | Attribuer maintenance, supervision et traitement des incidents. | Nommer un responsable du parcours complet. |
| Sortie | Vérifier les données et formats récupérables. | Prévoir code, documentation, accès et transfert. | Tester le remplacement séparé de chaque composant. |
La combinaison mérite d’être étudiée lorsque le socle standard convient mais qu’un parcours limité reste spécifique. Elle n’est pas automatiquement plus simple : l’interface entre les composants devient une partie du produit à exploiter.
Comparer le coût d’un service rendu
Comparer une licence annuelle au seul coût de développement initial produit un arbitrage incomplet. Sur un horizon commun, par exemple trois ans, choisi pour votre décision, inclure paramétrage ou construction, intégrations, migration, formation, fonctionnement, support, évolution et sortie.
Écrire les hypothèses qui font varier ce coût : utilisateurs, volumes, nombre d’interfaces, criticité, disponibilité attendue et fréquence des changements. Tester un scénario plus exigeant que le besoin de départ. Une comparaison reste utile même sans devis définitif, si les inconnues sont identifiées au lieu d’être remplacées par des montants arbitraires.
Microsoft recommande également d’inclure développement, infrastructure, maintenance et support dans l’évaluation du choix entre construire et acheter. Ce principe de coût complet ne désigne pas à lui seul l’option adaptée à votre métier.
Tester le point qui pourrait faire échouer le choix
Exemple illustratif. Une équipe souhaite gérer ses demandes de dérogation tarifaire. Le parcours habituel semble standard, mais certaines demandes doivent croiser une règle de marge, une validation régionale et des données issues de l’ERP.
Une démonstration générique de formulaire ne suffit pas à départager les options. Le test utile consiste à faire traiter une demande normale, une exception et une donnée source manquante, puis à récupérer la décision et son historique. Si le SaaS convient à ces cas sans contournements disproportionnés, cela constitue un argument concret en sa faveur. Si une règle centrale reste impossible à représenter, documenter précisément cette limite avant d’envisager une extension ou une construction.
Décider qui portera le produit après la livraison
Une solution sur mesure demande un responsable capable d’arbitrer ses évolutions. Une solution SaaS demande aussi quelqu’un pour gérer la configuration, les accès et l’adoption. Dans les deux cas, demander qui répond lorsqu’une interface échoue et comment une nouvelle règle métier devient une modification maîtrisée.
Le livrable de cadrage peut tenir dans une note claire : processus cible, contraintes, options examinées, coût avec hypothèses, test décisif, décision et conditions de réexamen. Notre offre Software & AI s’inscrit dans cette démarche. Lorsque le besoin touche la planification, la comparaison Anaplan/Pigment et les fondations data apportent deux lectures complémentaires.
