SaaS ou On-Premise : et si le véritable enjeu était de garder le choix ?

Depuis plusieurs années, le SaaS et le Cloud se sont progressivement imposés comme les modèles de référence dans l’industrie logicielle.

À tel point qu’un raccourci s’est installé : une solution moderne serait nécessairement une solution SaaS, exploitée dans le cloud par son éditeur.

Pour de nombreux usages, ce modèle apporte des bénéfices évidents : rapidité de mise en œuvre, exploitation déléguée, mises à jour prises en charge par l’éditeur et capacité à démarrer rapidement sans avoir à gérer l’infrastructure sous-jacente.

Mais doit-il pour autant devenir le modèle unique ?

La question mérite particulièrement d’être posée lorsqu’il s’agit de logiciels qui interagissent directement avec les systèmes critiques de l’entreprise : ordonnanceurs, plateformes d’orchestration, outils d’automatisation, solutions de transfert de fichiers ou, plus largement, composants chargés de piloter des processus au cœur du système d’information.

Dans ces environnements, le SaaS est une option. Il ne devrait pas nécessairement être une obligation.

Le système d’information des entreprises reste profondément hybride

La transformation vers le cloud est bien réelle. Mais elle n’a pas fait disparaître les infrastructures historiques.

Les systèmes d’information modernes sont aujourd’hui constitués d’un mélange d’environnements :

• Infrastructures On-Premise
• Clouds privés
• Clouds publics
• Environnements Kubernetes et conteneurisés
• Applications SaaS
• Infrastructures souveraines
• Systèmes historiques ou legacy toujours critiques pour l’activité

Cette hybridation n’est d’ailleurs pas nécessairement une situation transitoire. Pour de nombreuses entreprises, elle constitue désormais une architecture durable, résultant à la fois de choix technologiques, économiques, réglementaires et stratégiques.

Les applications migrent à des rythmes différents. Certaines données doivent rester localisées dans des environnements maîtrisés. Certains workloads sont économiquement plus pertinents On-Premise. D’autres bénéficient pleinement de l’élasticité du cloud.

Le système d’information de demain sera probablement moins « tout Cloud » que profondément hybride.

Et c’est précisément dans cet environnement que les plateformes d’orchestration doivent fonctionner.

Une plateforme d’orchestration occupe une position particulière

Une plateforme d’orchestration et d’automatisation n’est pas une application isolée.

Par définition, elle communique avec une multitude de composants du système d’information : ERP, bases de données, applications métier, systèmes de fichiers, API, environnements cloud, machines virtuelles, conteneurs, applications SaaS, plateformes de données ou encore systèmes historiques (Mainframes).

Elle déclenche des traitements, surveille leur exécution, transfère des données, gère des dépendances et intervient parfois directement dans des processus critiques pour l’activité de l’entreprise.

Elle se trouve donc au croisement de nombreux environnements du SI.

Dans ce contexte, imposer que cette plateforme soit nécessairement hébergée et exploitée à l’extérieur du système d’information peut introduire de nouvelles contraintes : connectivité supplémentaire, flux réseau vers l’extérieur, dépendance vis-à-vis d’une infrastructure tierce ou encore exigences spécifiques en matière de sécurité et de conformité.

Cela ne signifie pas que le SaaS soit inadapté. Cela signifie simplement que le choix du modèle d’exploitation devrait être déterminé par les besoins de l’entreprise, et non par le modèle imposé par l’éditeur.

On-Premise ne signifie plus « infrastructure lourde »

Une autre idée reçue consiste à associer automatiquement On-Premise à complexité.

Historiquement, cette perception pouvait être justifiée.

Installer un logiciel d’entreprise pouvait nécessiter plusieurs serveurs, des procédures d’installation complexes, des opérations de maintenance importantes et des montées de version nécessitant une forte mobilisation des équipes.

Mais les technologies ont considérablement évolué.

Conteneurs, Kubernetes, automatisation du déploiement, Infrastructure as Code, mécanismes modernes de haute disponibilité ou encore procédures de mise à jour automatisées permettent aujourd’hui de proposer des logiciels déployés chez le client avec un overhead opérationnel considérablement réduit.

Une solution peut donc être exploitée sur l’infrastructure du client tout en bénéficiant des principes qui ont fait le succès du cloud : automatisation, portabilité, standardisation et simplicité d’exploitation.

Le débat n’est donc plus réellement entre « logiciel moderne SaaS » et « ancien logiciel On-Premise ».

Il se situe davantage entre plateformes ouvertes sur leur modèle d’exploitation et plateformes qui imposent leur infrastructure.

37signals : quand sortir du cloud devient un choix économique et architectural

L’expérience de 37signals, l’entreprise derrière Basecamp et HEY, est particulièrement intéressante à ce titre.

Son cofondateur et CTO David Heinemeier Hansson (DHH), également créateur de Ruby on Rails, annonçait dès 2022 la décision de sortir progressivement une grande partie de leur infrastructure d’AWS et de Google Cloud.

Il ne s’agissait pourtant pas d’une entreprise découvrant le cloud : leurs équipes avaient exploité leurs applications pendant des années sur différentes infrastructures cloud, aussi bien sur des machines virtuelles que sur Kubernetes.

Dans son article « Why we’re leaving the cloud », DHH explique que, pour leur profil d’entreprise, avec des workloads importants mais relativement prévisibles, les économies et la réduction de complexité attendues du cloud ne s’étaient pas matérialisées comme ils l’espéraient.

👉 Article original de David Heinemeier Hansson

37signals a donc décidé de rapatrier une partie importante de ses applications sur sa propre infrastructure. L’opération s’est achevée en 2023 pour une grande partie de leurs workloads.

En 2024, DHH indiquait que leur facture cloud était passée d’un rythme d’environ 3,2 millions de dollars par an à 1,3 million, représentant près de 2 millions de dollars d’économies annuelles. Après prise en compte de la migration prévue de leurs quelque 10 pétaoctets encore stockés sur AWS S3, 37signals estimait désormais à plus de 10 millions de dollars les économies cumulées sur cinq ans.

Ce retour d’expérience est particulièrement intéressant car il remet en cause deux idées souvent associées au cloud : qu’il serait nécessairement plus économique et que l’exploitation d’une infrastructure propre nécessiterait obligatoirement beaucoup plus de ressources humaines.

DHH explique notamment que l’exploitation d’un service important dans le cloud n’est pas nécessairement « simple » : certaines opérations sont simplifiées, d’autres deviennent plus complexes. Selon lui, à l’échelle de 37signals, le passage au cloud n’avait pas permis de réduire significativement les équipes chargées des opérations.

Il reconnaît néanmoins clairement les situations dans lesquelles le cloud apporte une valeur considérable : démarrer rapidement avec peu d’infrastructure ou absorber des charges extrêmement variables et difficiles à prévoir.

C’est une nuance importante. Ce retour d’expérience ne démontre évidemment pas que toutes les entreprises devraient quitter le cloud.

Il illustre en revanche parfaitement un principe souvent oublié : le cloud est un modèle d’exploitation extrêmement puissant, mais il n’est pas nécessairement le modèle économiquement ou techniquement optimal pour chaque workload et chaque entreprise.

La bonne question n’est donc peut-être pas : « Comment migrer tout notre système d’information vers le cloud ? » mais plutôt : « Pour chaque workload, quel est le meilleur modèle d’exploitation ? »

Cloud-ready n’est pas synonyme de SaaS

C’est probablement l’une des distinctions les plus importantes.

Une plateforme cloud-ready doit pouvoir fonctionner efficacement dans des environnements cloud modernes. Mais cela ne signifie pas nécessairement qu’elle doive être opérée exclusivement par son éditeur.

Une architecture moderne peut permettre à une même plateforme d’être déployée :

• dans le datacenter du client
• sur son cloud privé
• sur une infrastructure Kubernetes
• auprès d’un hyperscaler
• sur un cloud souverain
• ou dans un environnement opéré par un prestataire de services

Cette portabilité apporte un avantage majeur : le choix de l’infrastructure reste entre les mains de l’entreprise / client.

Et ce choix peut évoluer dans le temps.

Une organisation peut commencer par exploiter la plateforme dans son datacenter, la déplacer ensuite vers un cloud privé ou souverain, puis décider ultérieurement d’en déléguer complètement l’exploitation. Sans nécessairement changer de technologie.

La souveraineté est aussi une question de liberté technologique

Les discussions autour de la souveraineté numérique se concentrent souvent sur la localisation des données. C’est évidemment un sujet essentiel, elle peut également être envisagée sous un angle plus large : la capacité d’une entreprise à choisir son infrastructure et à en changer.

Lorsqu’un logiciel n’existe que sous forme de SaaS, son infrastructure devient indissociable du produit. Changer de modèle d’hébergement peut alors signifier changer de logiciel.

À l’inverse, une plateforme portable permet de dissocier deux décisions : Quel logiciel voulons-nous utiliser ? Où voulons-nous l’exécuter ?

Cette séparation apporte une liberté stratégique supplémentaire.

Elle permet notamment aux entreprises de faire évoluer leur stratégie cloud, de répondre à de nouvelles exigences réglementaires ou de choisir un fournisseur souverain sans nécessairement remettre en cause leur plateforme d’orchestration.

Le modèle économique doit également entrer dans l’équation

Le choix entre SaaS et infrastructure maîtrisée n’est pas uniquement technique. Il est également économique.

Le SaaS permet de déléguer une partie importante des responsabilités opérationnelles et de bénéficier d’un service directement exploitable.

Pour certaines organisations, c’est exactement le modèle recherché. Pour d’autres, disposant déjà d’une infrastructure, de plateformes Kubernetes industrialisées et d’équipes capables de les exploiter, payer durablement une couche d’hébergement supplémentaire peut ne pas apporter la même valeur.

Une entreprise ayant déjà investi dans son cloud privé ou son infrastructure Kubernetes peut souhaiter capitaliser sur cette infrastructure plutôt que payer une seconde fois pour une capacité qu’elle possède déjà.

Il faut également considérer cette équation dans la durée. Un coût mensuel particulièrement attractif au démarrage peut prendre une toute autre dimension lorsque les volumes, le stockage, les flux ou la puissance nécessaire augmentent pendant plusieurs années.

Il n’existe pas de modèle économiquement optimal dans toutes les situations. La capacité de choisir devient essentielle.

La stratégie Visual TOM : un produit, plusieurs modèles d’exploitation

Chez Absyss, cette conviction structure directement notre stratégie autour de Visual TOM.

Nous ne considérons pas l’On-Premise, le cloud et le SaaS comme trois générations successives de logiciels dont l’une devrait nécessairement remplacer les autres.

Nous développons une plateforme d’orchestration moderne, portable et cloud-ready, capable de s’adapter à la stratégie d’infrastructure de nos clients.

Visual TOM peut ainsi être déployé :

• directement dans l’infrastructure de l’entreprise
• dans son cloud privé
• sur une infrastructure Kubernetes
• auprès d’un hyperscaler
• sur un cloud souverain
• ou être exploité sous forme de service managé par l’un de nos partenaires

Pour les entreprises qui souhaitent conserver la maîtrise de leur infrastructure, Visual TOM reste donc directement exploitable dans leur environnement.

Pour celles qui souhaitent déléguer ces opérations, notre écosystème de partenaires peut prendre en charge l’hébergement, l’administration et l’exploitation de la plateforme afin de fournir Visual TOM sous forme de service.

Le même produit, les mêmes capacités, plusieurs modèles d’exploitation, le client choisit.

Simplifier l’exploitation plutôt que supprimer le choix

Notre objectif est également de réduire progressivement la différence opérationnelle entre une plateforme exploitée directement par le client et une plateforme consommée comme un service.

Déploiement conteneurisé, automatisation, Kubernetes, simplification des montées de version, mécanismes de haute disponibilité : les technologies modernes permettent aujourd’hui de rendre l’exploitation d’une plateforme On-Premise ou cloud privé beaucoup plus simple qu’elle ne l’était historiquement.

C’est selon nous une évolution fondamentale. La simplicité d’exploitation ne doit plus nécessairement être obtenue au prix de l’abandon du contrôle de l’infrastructure. Les entreprises doivent pouvoir bénéficier des deux.

Le SaaS est une excellente option. L’absence de choix l’est moins.

Le SaaS et le cloud ont profondément amélioré la manière dont nous consommons et exploitons le logiciel. Il n’est évidemment pas question de revenir en arrière.

L’expérience de 37signals montre simplement qu’après des années de « cloud first », il peut être pertinent de réexaminer certains choix en fonction de critères très pragmatiques : coûts, performances, maîtrise, prévisibilité des workloads ou indépendance technologique. Ce principe s’applique également au Saas.

Chez Absyss, nous pensons que les plateformes d’infrastructure doivent accompagner cette liberté plutôt que la restreindre.

Les architectures modernes permettent aujourd’hui de concilier simplicité, automatisation, portabilité, souveraineté et liberté d’exploitation.

C’est cette philosophie que nous défendons avec Visual TOM.

Parce qu’à mesure que les systèmes d’information deviennent plus hybrides, les entreprises auront besoin de plateformes capables de s’adapter à leur architecture — et non d’architectures contraintes de s’adapter à leur plateforme.

Le futur de l’orchestration n’est peut-être ni SaaS, ni On-Premise. Il est hybride, portable et surtout : choisi.