Un RSSI m’a dit un jour : « Le cloud, c’est juste le serveur de quelqu’un d’autre. » La formule est un peu provocatrice, mais elle pose une vraie question : qui contrôle réellement l’infrastructure et les données lorsque l’on choisit une solution SaaS ?
Depuis plusieurs années, les applications métiers migrent progressivement vers le cloud. Le mouvement répond à des besoins très concrets de flexibilité, de disponibilité et de réduction de la charge d’exploitation pour les DSI. Mais avec la multiplication des cyberattaques et le renforcement des exigences liées au RGPD, le choix entre SaaS et On-Premise mérite d’être analysé au cas par cas.
Cyberattaques en hausse, exigences de souveraineté, réglementation qui se durcit : le débat SaaS vs On-Premise n’a jamais été aussi vif. Pour les directions des systèmes d’information (DSI) et les ingénieurs sécurité, le choix de l’architecture ne dépend pas d’une simple tendance, mais d’une analyse rigoureuse des risques et des besoins d’externalisation.
Le stockage des données d’audit, des fiches de non-conformité et des informations liées aux processus internes mérite une attention particulière. Ces données peuvent contenir des informations sensibles sur l’organisation, ses fournisseurs, ses contrôles internes ou encore ses écarts de conformité.
Leur niveau de protection doit donc être défini en fonction de leur criticité, de leur confidentialité et des conséquences potentielles d’une perte, d’une fuite ou d’une indisponibilité.
Dans les faits, la plupart des éditeurs sérieux de logiciel QMS (Quality Management System) proposent aujourd’hui les deux, et c’est tant mieux, parce qu’un choix imposé finit toujours par coincer un client quelque part.
Pour guider les architectes logiciels et les responsables de la sécurité des systèmes d’information (RSSI), il convient de comparer les protocoles de chiffrement, la gestion des correctifs, la résilience des infrastructures et la conformité légale de ces deux modèles.
L’architecture SaaS : Mutualisation, chiffrement et gestion des correctifs
Le modèle SaaS repose sur l’utilisation d’une application hébergée et exploitée par un fournisseur. L’entreprise délègue ainsi une partie importante de l’infrastructure : serveurs, maintenance, mises à jour et, selon le service proposé, supervision, sauvegardes ou haute disponibilité.
C’est l’un des principaux avantages du SaaS pour une DSI : le patch management et l’exploitation de l’infrastructure sont assurés par un acteur dont c’est le métier. Lorsqu’une vulnérabilité critique ou une faille Zero-Day est identifiée, le fournisseur peut déployer les correctifs sur son périmètre sans que chaque client ait à intervenir directement sur les serveurs.
Cela ne signifie toutefois pas que toute la sécurité est externalisée : la gestion des utilisateurs, des droits d’accès et de la configuration de l’application reste généralement sous la responsabilité du client.
Dans une infrastructure On-Premise, l’application d’un correctif dépend directement des processus de la DSI : identification de la vulnérabilité, qualification du patch, tests de compatibilité, planification de l’intervention puis déploiement. Selon la criticité du système et l’organisation en place, ce délai peut créer une fenêtre d’exposition entre la publication d’un correctif et sa mise en production.
Le SaaS permet au contraire de mutualiser cette opération entre les différents clients de la plateforme, même si le niveau de réactivité dépend évidemment du fournisseur et de ses procédures de gestion des vulnérabilités.
Côté chiffrement, les solutions SaaS professionnelles proposent aujourd’hui généralement des mécanismes de protection des données en transit et au repos. On retrouve notamment TLS 1.3 pour sécuriser les communications et AES-256 pour le chiffrement des données stockées.
Mais ces technologies ne suffisent pas à elles seules à évaluer la sécurité d’un SaaS. La question de la gestion des clés de chiffrement est tout aussi importante : qui détient les clés ? Qui peut y accéder ? Comment sont-elles protégées et renouvelées ?
C’est notamment là que des mécanismes comme le BYOK (Bring Your Own Key) peuvent apporter un niveau de contrôle supplémentaire aux entreprises qui souhaitent conserver la maîtrise de leurs clés de chiffrement.
La résilience est native dans le cloud : la redondance géographique et les plans de reprise d’activité (PRA) automatisés garantissent une haute disponibilité difficile et coûteuse à répliquer sur des infrastructures internes.
L’architecture On-Premise : maîtrise des données et isolation réseau
À l’opposé du SaaS, le modèle On-Premise offre à l’entreprise une maîtrise directe de son infrastructure et de sa pile technologique. Pour certaines industries fortement réglementées — défense, santé, secteur public ou aéronautique par exemple — cette capacité de contrôle peut être un critère déterminant.
En installant le logiciel dans son propre centre de données, la DSI maîtrise notamment l’architecture réseau, la segmentation, les règles de filtrage et les accès aux serveurs. Elle réduit ainsi sa dépendance à un fournisseur pour l’hébergement de l’application.
En revanche, un environnement On-Premise peut toujours communiquer avec des réseaux externes : accès distants, VPN, API, services partenaires ou applications exposées sur Internet. La sécurité dépend donc de l’architecture réellement mise en place et de la manière dont ces différents accès sont protégés.
L’isolation de certains systèmes peut réduire leur exposition directe aux attaques provenant d’Internet, notamment lorsque l’architecture réseau est correctement segmentée. Cela peut limiter certains scénarios d’attaque DDoS, d’intrusion ou de propagation d’une compromission.
Le risque n’est cependant jamais nul. Une infrastructure On-Premise peut elle aussi être victime d’une compromission de compte, d’un ransomware, d’une faille applicative ou d’une attaque visant un service exposé. La réduction de la surface d’attaque dépend donc avant tout de la segmentation réseau, des contrôles d’accès et des dispositifs de sécurité déployés.
La souveraineté numérique est le second argument fort du On-Premise. Avec le durcissement des réglementations comme le RGPD en Europe, la localisation physique des serveurs est devenue un enjeu juridique. Une infrastructure sur site élimine le risque d’extranéité juridique, notamment lié aux lois extraterritoriales comme le Cloud Act américain. De plus, le On-Premise permet une granularité totale dans la gestion des droits d’accès et de l’authentification. L’intégration avec l’Active Directory local ou un système IAM (Identity and Access Management) interne se fait sans l’utilisation de passerelles cloud complexes, réduisant la surface d’attaque globale du système d’information.
Le coût caché de la sécurité : Comparatif des responsabilités
Une idée reçue consiste à croire que le SaaS est nativement plus sûr que le On-Premise, ou inversement. En réalité, tout dépend du modèle de responsabilité partagée. En mode SaaS, la sécurité du cloud incombe au fournisseur (sécurité physique des datacenters, virtualisation, réseau de base), tandis que la sécurité dans le cloud incombe au client (gestion des identités, droits d’accès, configuration de l’application). Trop souvent, les fuites de données dans le cloud ne proviennent pas d’une faille de l’hébergeur, mais d’une mauvaise configuration des droits d’accès par l’entreprise utilisatrice.
En mode On-Premise, la responsabilité de l’entreprise est totale. Cela exige des ressources humaines et matérielles considérables. Maintenir des serveurs physiques obsolètes, négliger les mises à jour du firmware des pare-feu ou omettre la mise en place d’un système de détection des intrusions (IDS) rend une infrastructure locale bien plus vulnérable qu’un cloud managé par des experts certifiés ISO 27001. Le On-Premise offre un contrôle absolu, mais il transfère également l’intégralité du risque opérationnel et financier sur les épaules de la DSI.
Vers des modèles hybrides et des solutions modulaires
Face à ce dilemme, le marché logiciel évolue vers des solutions plus flexibles. De nombreux éditeurs ne forcent plus le passage au tout-cloud et conçoivent des applications capables de s’adapter aux contraintes techniques de leurs clients. Qu’il s’agisse d’un déploiement SaaS managé dans un cloud souverain ou d’une intégration sur les serveurs privés de l’entreprise, l’architecture logicielle doit rester transparente pour l’utilisateur final.
Cette flexibilité permet aux entreprises de segmenter leurs données en fonction de leur criticité. Une organisation peut ainsi faire le choix du SaaS pour ses outils de productivité quotidienne, tout en maintenant On-Premise ses bases de données de recherche et développement ou ses systèmes de pilotage de la conformité. Tout repose alors sur des API bien sécurisées pour faire circuler les données entre les deux mondes. Sur le papier c’est élégant. En pratique, ça demande une vraie discipline côté intégration.
La question à se poser avant de signer
Le choix entre SaaS et On-Premise n’est pas binaire, et il ne devrait jamais se décider en réunion budget seule. RSSI et DSI doivent être à la table dès le départ. Si le SaaS s’impose pour sa scalabilité, sa résilience native et sa simplicité de maintenance, le On-Premise demeure le choix de l’indépendance pour les organisations exigeant un cloisonnement réseau strict et une souveraineté numérique sans concession. Une question à se poser avant de trancher : si demain votre fournisseur cloud fermait boutique du jour au lendemain, combien de temps tiendrait votre activité ? La réponse dit souvent plus long que n’importe quel comparatif technique.