Logiciel sur mesure, SaaS ou no-code : comment choisir ?
Un outil existant peut être le meilleur choix. Encore faut-il regarder ce qu’il couvre, les règles qui vont s’accumuler et les moyens de reprendre la main. Odoo, n8n, Firebase et nos projets éclairent ces décisions.
Terrain
Sur une plateforme que nous accompagnions, une partie réseau social avait été confiée à une brique existante. L'idée semblait raisonnable : utiliser ce qui était déjà disponible et concentrer le développement sur le reste. Puis les adaptations se sont accumulées. Faire évoluer cette brique est devenu plus difficile que de la reconstruire.
Nous avons finalement recodé cette partie. Un outil prêt à l'emploi peut faire gagner beaucoup de temps au départ, puis demander trop de compromis lorsque le besoin s'en éloigne.
Logiciel sur mesure, SaaS ou no-code : comment choisir ? Notre première question est simple : existe-t-il déjà un outil qui fait ce dont vous avez besoin ? S'il convient aux usages, au budget et aux contraintes d'exploitation, nous pouvons le recommander, voire aider à l'installer. Le sur mesure devient intéressant lorsqu'il permet de résoudre une difficulté que les outils disponibles prennent mal en charge.
Ces trois termes ne désignent pas exactement la même chose
Un SaaS est un logiciel proposé comme un service hébergé, souvent avec un abonnement. Le no-code permet de construire ou de configurer une application sans écrire l'essentiel de son code. Le low-code combine cette approche avec des développements complémentaires. Une application sur mesure est construite pour les besoins de l'organisation.
Ces possibilités peuvent se combiner. Un outil no-code peut être un SaaS, ou être hébergé dans un environnement choisi par l'organisation. Une application sur mesure peut s'appuyer sur des services SaaS pour certaines fonctions. Il faut donc examiner à la fois la façon de construire l'outil et la manière dont il sera exploité.
| Approche | Quand elle mérite d'être examinée | Le point à vérifier |
|---|---|---|
| Un SaaS existant | Le besoin est bien couvert par un produit disponible, avec des adaptations limitées. | Le coût complet, les possibilités d'intégration, l'accès aux données et les limites de personnalisation. |
| Une construction no-code ou low-code | Les équipes veulent visualiser et modifier des processus dans une interface graphique adaptée. | La complexité des règles, la documentation et la capacité d'une autre personne à reprendre l'ensemble. |
| Une application sur mesure | Les outils existants couvrent mal les règles métier, les performances ou la maîtrise recherchée. | Le budget de conception et d'affinage, les moyens de maintenir le code et les dépendances choisies. |
Un bon outil existant peut être le meilleur point de départ
Nous avons déjà conseillé à des prospects de regarder Odoo, une suite logicielle qui couvre de nombreux besoins de gestion. Si les fonctions disponibles correspondent au travail attendu et que le coût convient, il n'y a pas de raison de reconstruire leur équivalent pour le principe.
La disponibilité du produit ne rend toutefois pas toute la mise en place instantanée. Paramétrage, migration des données, formation et connexions aux autres outils peuvent demander un travail réel. La bonne question est ce qu'il faudra encore faire pour utiliser le logiciel dans les conditions de l'organisation.
Nous recherchons une forte adéquation entre le besoin et l'outil. Si l'essentiel tient dans son périmètre, il peut donner une réponse rapide et lisible. Si chaque étape nécessite un contournement, une exportation manuelle ou une exception, il faut examiner ce que ces écarts coûteront au fil du temps.
Le no-code rend les processus visibles, sans supprimer leur complexité
Nous avons nous-mêmes utilisé n8n et d'autres outils de cette famille. Leur intérêt est notamment de rendre un processus visible : on voit les étapes, les conditions et les connexions. Modifier le schéma peut être une manière pratique de faire évoluer le fonctionnement. Le choix d'hébergement dépend de l'outil : n8n propose notamment une possibilité d'auto-hébergement.
Dans notre pratique, l'arrivée de l'IA a réduit l'intérêt de certains usages du no-code. Nous pouvons produire et modifier du code en dialoguant avec des outils d'IA, à l'écrit ou à l'oral. Le choix dépend alors moins de la possibilité d'éviter la programmation que de la manière dont l'équipe préfère comprendre et piloter le processus.
Nous rencontrons régulièrement une situation moins confortable : une personne a construit un ensemble de processus visuels, puis elle quitte l'organisation. Les outils continuent à fonctionner, mais personne ne sait vraiment les faire évoluer. Les exceptions se sont accumulées, les règles sont dispersées et la performance peut devenir un sujet.
La personne qui avait conçu l'ensemble portait une connaissance du produit et une capacité à organiser sa complexité. Un schéma ne transmet pas automatiquement cette compréhension. Un ensemble de dizaines ou de centaines de schémas peut être aussi difficile à reprendre qu'une base de code mal organisée.
La complexité ne disparaît pas parce qu'on la représente avec des blocs et des flèches.
Le code classique a un avantage dans certaines reprises : il existe un vivier de personnes formées aux langages et aux pratiques de développement concernés. Encore faut-il que le code soit organisé, documenté et testé. La même exigence de transmission vaut pour les outils visuels.
Le sur mesure devient pertinent quand les écarts comptent vraiment
Un besoin apparaît souvent à partir d'un point de douleur : une tâche trop lente, des données difficiles à rapprocher, un outil qui empêche une manière de travailler jugée meilleure. Les équipes envisagent alors ce qu'elles pourraient gagner en faisant autrement.
Le cadrage sert à examiner cette possibilité. Quels avantages attend-on ? Quels inconvénients le changement introduit-il ? Une habitude peut évoluer pour entrer dans un outil existant, tandis qu'une règle métier importante peut justifier de construire autre chose. Cette décision se prend en regardant le travail réel.
Dans notre expérience, trois enjeux font particulièrement pencher vers le sur mesure :
- La complexité à organiser. Les règles et leurs exceptions s'articulent mal avec les produits disponibles, ou leur adaptation devient trop coûteuse.
- La maîtrise de ce qui est construit. L'organisation veut savoir où se trouvent ses données, sous quelle forme, et disposer du code pour faire évoluer la solution.
- Les contraintes d'exploitation. Volumes, calculs ou visualisations demandent des choix techniques que l'outil existant permet difficilement.
Sur certains projets, des composants de calcul en Rust peuvent par exemple répondre à des enjeux de performance, y compris dans une application web. Le langage découle de la contrainte. Il n'est pas, à lui seul, une raison de développer sur mesure.
Maîtriser le code et les données demande des choix explicites
Un SaaS ne donne généralement pas la maîtrise de son implémentation. Les possibilités de personnalisation, d'export et d'intégration dépendent du produit et de l'offre retenue. Cela n'empêche pas de l'utiliser correctement, mais il faut connaître ces limites avant de lui confier une fonction importante.
Inversement, disposer d'un code sur mesure ne rend pas automatiquement l'organisation autonome. Elle doit pouvoir l'héberger, le maintenir et confier sa reprise à une équipe compétente. Dans nos projets, les sources appartiennent au client et sont remises avec la documentation technique et fonctionnelle.
Nous examinons donc concrètement l'accès aux données, leurs formats de sortie, l'hébergement, les services externes et les moyens de changer d'équipe. Une dépendance peut être utile et assumée. Elle devient gênante quand on la découvre au moment où l'on veut faire évoluer l'application.
Une application sur mesure peut garder des briques SaaS
La plateforme EtreProf d'Ecolhuma utilise, dans sa dernière version, Firebase pour une partie de l'authentification. Firebase Authentication fournit des services d'authentification intégrables à une application. La plateforme conserve son fonctionnement métier, tout en s'appuyant sur cette brique externe.
Dans les systèmes de gestion de données, on rencontre aussi des services comme BigQuery connectés à des outils internes. Les API permettent de faire travailler ensemble des composants qui ne relèvent pas tous du même mode de construction ou d'hébergement.
La frontière utile consiste à regarder où chaque brique rend service et où les échanges deviennent difficiles à maintenir. Il faut comprendre quelles données circulent, où se trouvent les règles métier et ce qui se passe lorsqu'un service change. Une combinaison bien choisie peut éviter de développer inutilement une fonction déjà disponible.
L'IA rend certaines personnalisations plus accessibles
L'IA a changé l'équilibre dans notre pratique. Produire une fonctionnalité spécifique ou modifier du code maîtrisé est devenu plus rapide. Sur la plateforme dont nous avons recodé la partie réseau social, la difficulté à adapter la brique existante a fini par rendre une réalisation propre plus pertinente.
Cette évolution ne rend pas tous les SaaS inutiles. Leur exploitation et les fonctions qu'ils couvrent gardent une valeur. Elle invite à réexaminer certains compromis : ce qui aurait été trop coûteux à développer auparavant peut devenir envisageable.
Il reste du travail pour concevoir la bonne solution, traiter les cas particuliers et vérifier les usages. Les gains sur la production du code et sur les tests sont réels dans nos projets, mais la complexité métier demande toujours du jugement et des échanges. Notre article sur le prix d'un logiciel métier sur mesure explique ce que cela change dans les budgets.
Comparer le coût et la capacité d'évolution sur trois à cinq ans
Un abonnement donne un repère récurrent. Son coût total peut néanmoins évoluer avec les utilisateurs, les usages, les options ou les tarifs. Une application sur mesure demande un investissement initial, puis de la maintenance, de l'hébergement et des évolutions. Une construction no-code a également un coût de conception et de suivi.
Pour comparer, nous regarderions au moins les postes suivants :
- La mise en place : paramétrage ou développement, migration, intégrations et formation.
- L'exploitation : abonnements, hébergement, services externes et temps d'administration.
- Les changements : nouvelles règles, nouveaux profils et adaptations au fil des usages.
- La transmission : documentation, reprise par une autre personne et récupération des données.
La complexité tend à augmenter avec les années : de nouveaux cas apparaissent, puis des exceptions. Si l'on anticipe cette croissance autour d'une brique peu adaptable, la prudence s'impose. Le prix de départ ne suffit pas à départager les solutions, et il serait trompeur de donner une formule universelle de rentabilité.
Six questions pour commencer la décision
- Quel problème voulez-vous résoudre ? Décrivez la difficulté actuelle et les gains attendus.
- Avez-vous identifié un outil qui le fait déjà ? Examinons-le avant de reconstruire.
- Quelle part du besoin entre réellement dans son fonctionnement ? Regardons les écarts et les contournements nécessaires.
- Cette complexité va-t-elle augmenter ? Anticipons les nouveaux usages et les exceptions.
- Que devez-vous maîtriser ? Données, hébergement, code, performance et capacité à changer de prestataire.
- Qui pourra faire évoluer l'ensemble dans quelques années ? Prévoyons les compétences, la documentation et le budget de suivi.
Vous pouvez arriver avec un outil pressenti, un existant à remplacer ou simplement une difficulté à expliquer. Notre offre de logiciels métier sur mesure présente la manière dont nous accompagnons ce choix et sa réalisation. Discutons de votre contexte et des solutions déjà disponibles.