SaaS vs. On‑Premise : cadre décisionnel pour la conformité et la souveraineté des données

La décision SaaS vs. On‑Premise ne devient réellement critique dans de nombreuses organisations que lorsque les exigences de conformité et de souveraineté des données se concrétisent : où sont les données ? Qui dispose d’un accès administratif ? Comment réussir un audit sans se fier à des hypothèses ? Et comment sortir, le cas échéant, sans lancer des projets de migration de plusieurs mois sous contrainte de temps ?

En pratique, la question « cloud ou pas » est rarement la bonne. Ce qui compte, c’est si le modèle d’exploitation choisi répond à vos exigences de conformité légale, de traçabilité (audit), de maîtrise des risques et de gouvernance opérationnelle — sur l’ensemble du cycle de vie, pas seulement au moment de la mise en production. Cet article propose un cadre de décision solide qui aligne la direction IT, la conformité, la sécurité, les achats et la direction générale sur une logique d’évaluation commune. L’accent est mis sur la faisabilité, les responsabilités et les contrôles documentables.

Clarifier les notions : souveraineté des données, résidence des données et Shared Responsibility

Souveraineté des données ne signifie pas seulement « les données sont chez nous ». Il s’agit de la capacité à faire respecter l’usage des données : maîtriser les accès, contrôler les clés, déclencher des suppressions de manière démontrable, extraire des exports et RESTer opérationnel en cas de conflit (p. ex. demandes d’autorités). Résidence des données est plus RESTreinte : elle décrit dans quelle région ou quel pays les données sont stockées et traitées.

Pour les offres SaaS, on utilise souvent le concept de Shared Responsibility : le fournisseur et le client se partagent les responsabilités. Ce n’est pas un terme marketing, il doit se traduire en contrôles. Typiquement : le fournisseur est responsable de la plateforme (centre de données, sécurité de base, patching de l’application SaaS), le client est responsable des identités, des rôles, de la classification des données, des autorisations, de la configuration et de l’utilisation correcte. En On‑Premise, la responsabilité vous incombe presque entièrement — en contrepartie, les preuves et les droits d’intervention sont au maximum sous votre contrôle.

Pourquoi la « conformité » sans perspective d’audit n’est pas suffisante

Beaucoup d’exigences ne sont satisfaites que lorsqu’elles sont vérifiables : par la révision interne, des auditeurs externes, des audits clients ou des autorités. L’important est de pouvoir répondre clairement aux questions suivantes :

• Quels contrôles existent ? (p. ex. contrôle d’accès, journalisation, gestion des clés, sauvegarde/RESTauration)
• Comment les contrôles sont-ils mis en œuvre ? (configuration, processus, responsables)
• Comment l’efficacité est‑elle démontrée ? (logs, rapports, protocoles de test, preuves de changement)
• Comment réagit‑on aux écarts ? (processus incident, escalade, mesures correctives)

Un fournisseur SaaS peut fournir de nombreuses preuves (p. ex. rapports SOC), mais celles‑ci ne couvrent pas automatiquement ce qui est pertinent pour votre entreprise. Inversement, l’On‑Premise peut théoriquement tout couvrir, mais échoue en pratique à cause de capacités humaines limitées, d’une maturité des processus insuffisante ou d’une documentation manquante. Le cadre de décision doit donc représenter les deux dimensions : la contrôlabilité et la capacité opérationnelle réelle.

SaaS vs. On‑Premise: Die wichtigsten Entscheidungsdimensionen

Plutôt qu’une liste générique d’avantages/inconvénients, il est préférable d’évaluer sur des dimensions stables. Chaque dimension est ensuite traduite en exigences que vous pouvez ancrer dans le RFP, le contrat et l’exploitation.

1) Classification des données et niveau de protection comme point de départ

Sans classification des données, les discussions sur SaaS vs. On‑Premise tournent souvent à l’intuition. Une classification pragmatique (par ex. public / interne / confidentiel / strictement confidentiel) suffit si elle est appliquée de façon cohérente. Il est important de définir le niveau de protection : confidentialité, intégrité, disponibilité et traçabilité (audit trail).

Règle pratique : plus le niveau de protection est élevé, plus les contrôles techniques (par ex. gestion des clés) et les contrôles organisationnels (par ex. processus d’attribution des droits) doivent être stricts. Le SaaS peut satisfaire ces exigences — mais seulement si les mécanismes proposés correspondent à votre modèle.

2) Accès, droits d’administration et séparation des locataires

Dans les environnements SaaS, la question la plus critique n’est souvent pas « le fournisseur peut‑il voir les données ? », mais qui peut intervenir administrativement et dans quelles conditions. Cela inclut les accès de support, les accès d’urgence, les sous‑processeurs et le modèle d’autorisations interne du fournisseur. La séparation des locataires (Multi‑Tenancy) est courante en SaaS. Elle n’est pas a priori moins sûre, mais exige une séparation technique et organisationnelle vérifiable ainsi que des garanties claires concernant les environnements de test, de staging et de production.

L’On‑Premise vous donne le contrôle maximal sur les accès administratifs – cela signifie toutefois que vous devez effectivement mettre en œuvre MFA, Privileged Access Management (PAM, c.-à-d. accès administrateur contrôlés avec journalisation) et hardening. Sans ces mesures, « On‑Premise » n’est pas automatiquement plus sûr.

3) Chiffrement et gestion des clés (KMS, BYOK, HYOK)

Le chiffrement n’est un argument de souveraineté des données que si la gestion des clés est appropriée. Quelques termes qui reviennent souvent dans les discussions d’achat :

• KMS (Key Management Service) : service de gestion des clés cryptographiques, incluant rotation et règles d’accès.
• BYOK (Bring Your Own Key) : vous fournissez la clé, le fournisseur l’utilise dans son infrastructure, souvent sous votre contrôle pour la rotation/la désactivation.
• HYOK (Hold Your Own Key) : les clés RESTent dans votre environnement ; le fournisseur ne peut pas déchiffrer sans votre intervention. C’est techniquement plus exigeant et pas disponible dans tous les SaaS.

Pour la conformité, les points centraux sont : qui peut activer, faire tourner et bloquer les clés ? Et : quelles données sont chiffrées et comment ? (at REST, c’est‑à‑dire stockées ; in transit, c’est‑à‑dire transmises ; éventuellement côté client). L’On‑Premise permet typiquement un contrôle total, mais exige des processus matures (rotation, sauvegarde des clés, scénarios de récupération).

4) Journalisation, piste d’audit et conservation des preuves

La possibilité d’auditer dépend des journaux : qui a consulté, modifié, exporté ou supprimé quelles données et quand ? Pour de nombreux dispositifs (système de contrôle interne, protection des données, normes de sécurité), vous avez besoin de chaînes d’événements traçables. Pour le SaaS, il est important de savoir si vous pouvez exporter les données brutes (p. ex. événements administrateur) et pendant combien de temps elles sont conservées. En On‑Premise, il est crucial que la journalisation ne soit pas seulement « activée », mais qu’elle soit analysée de manière centralisée et stockée de façon résistante à la manipulation (principe Write‑Once‑Read‑Many ou dépôt conforme aux exigences de conservation).

Pour l’acquisition, une question concrète est décisive : le système peut-il fournir les journaux à votre SIEM (Security Information and Event Management, analyse centrale de la sécurité), y compris avec un niveau de détail suffisant et des interfaces stables ?

5) Résidence des données, sous‑processeurs et transferts transfrontaliers

Les exigences en matière de protection des données et les obligations sectorielles exigent souvent une clarté sur où les données sont traitées et qui y participe. Pour le SaaS, la chaîne des sous‑processeurs est centrale : hébergement, support, monitoring, gestion des incidents, fournisseur de messagerie, systèmes de ticketing. Vous avez besoin de transparence, de processus de modification et de possibilités d’opposition. L’On‑Premise minimise cette chaîne, mais la remplace par vos propres pRESTataires (p. ex. maintenance, centre de données, services managés) — qui doivent eux aussi être intégrés de manière contractuelle et organisationnelle.

6) Continuité d’activité : Backup, RESTore, RTO/RPO, exploitation en situation de crise

La conformité et la souveraineté des données concernent également la disponibilité. Deux indicateurs doivent figurer dans chaque décision :

• RPO (Recovery Point Objective) : perte de données maximale tolérable en durée (p. ex. 15 minutes).
• RTO (Recovery Time Objective) : délai maximal de redémarrage tolérable (p. ex. 4 heures).

Le SaaS peut être performant sur ces points, mais vous devez vérifier ce qui est garanti contractuellement : fréquence des sauvegardes, tests de RESTauration, pannes régionales, dépendance aux services d’identité, temps de réaction du support en cas d’incident majeur. L’On‑Premise peut être optimisé précisément pour vos RTO/RPO — mais cela exige de la planification, une redondance matérielle, des tests de RESTauration réguliers et des runbooks fiables.

7) Gestion des changements et des correctifs en tant que facteur de conformité

Dans le SaaS, les changements sont souvent appliqués en continu. C’est bénéfique pour les mises à jour de sécurité, mais cela peut introduire des risques pour la validation, les interfaces et les processus métier. Cela devient pertinent pour la conformité lorsque vous devez suivre et évaluer les modifications : quelles releases sont prévues ? Y a‑t‑il des notes de version ? Des annonces préalables ? Des fonctionnalités peuvent‑elles être désactivées ou « verrouillées » ?

En On‑Premise, vous gérez vous‑mêmes les patches et les releases. Cela réduit les surprises, mais augmente le risque que des mises à jour soient retardées. Lors d’un audit, « nous aurions pu patcher » n’exonère pas si des vulnérabilités connues RESTent ouvertes pendant des mois.

Transformer les exigences réglementaires en une logique de contrôle vérifiable

Que vous vous référeriez aux standards ISO, aux exigences sectorielles ou aux cadres réglementaires : l’essentiel est la traduction en exigences vérifiables. Exemples de facteurs fréquents (sans prétention d’exhaustivité) :

• Protection des données (p. ex. RGPD) : sous‑traitance, concepts de suppression, droits des personnes concernées, mesures techniques et organisationnelles.
• NIS2 : responsabilité de la direction, mesures de sécurité, processus de notification, risques liés à la chaîne d’approvisionnement.

Important pour « Approvvigionamento » : ces facteurs ne doivent pas figurer comme des buzzwords dans un RFP, mais comme des exigences de contrôle concrètes assorties de preuves, de responsabilités et de droits d’audit.

Cadre de décision : des exigences à une sélection robuste

Le cadre ci‑dessous fonctionne comme un processus pouvant être intégré aux achats, à la gouvernance et à la planification projet. Il contraint à clarifier les points ouverts tôt — avant que le contrat et l’architecture technique ne fassent office de faits accomplis.

Étape 1 : définir les Minimum Controls (non négociables)

Définissez une liste de contrôles minimums valables indépendamment du modèle d’exploitation. Exemples :

• MFA pour tous les accès administratifs ; principe de rôles avec Least Privilege (droits strictement nécessaires).
• Piste d’audit traçable pour les actions critiques (p. ex. changements d’autorisations, exports, suppressions).
• Résidence des données définie ou dérogation motivée avec contrôles de transfert.
• Chiffrement en transit et au repos ; gestion des clés documentée incluant la rotation.
• Concept de sauvegarde/RESTauration avec tests réguliers de RESTauration et RTO/RPO clairement définis.
• Processus d’incident avec délais de notification, points de contact et support forensic.

Ces Minimum Controls constituent le noyau de votre position de conformité. Si un fournisseur (ou votre propre organisation On‑Prem) ne peut les satisfaire, la discussion est close ou une acceptation formelle du risque au niveau directionnel est nécessaire.

Étape 2 : cartographie des contrôles et responsabilités (RACI)

Pour chaque objectif de contrôle, définissez qui est Responsible (exécutant), Accountable (redevable), Consulted (consulté) et Informed (informé). Surtout avec le SaaS, des lacunes apparaissent quand tout le monde part du principe que « le fournisseur s’en occupe ».

Pièges courants dans une matrice RACI : gestion des identités (SSO, c’est‑à‑dire Single Sign‑On), gestion des autorisations, exports de données, demandes de suppression, décisions sur les clés et conservation des logs. Traitez ces points comme des lignes distinctes de votre matrice.

Étape 3 : établir un plan de preuves pour les audits

Un plan de preuves est une liste de justificatifs que vous pouvez fournir sur simple demande. Exemples :

• Extrait de configuration relatif à MFA/SSO et aux rôles admin
• Compte rendu d’un test de RESTauration (date, périmètre, résultat, écarts)
• Validations de changements pour des adaptations sensibles à la sécurité
• Liste des sous‑processeurs avec historique des modifications
• Extrait d’événements SIEM pour actions critiques (réduction aux données nécessaires)

Important : concevez les preuves pour qu’elles RESTent disponibles même si le SaaS‑Tenant est bloqué ou que des systèmes On‑Prem sont isolés lors d’un incident.

Étape 4 : stratégie de sortie et portabilité comme chapitre obligatoire

La conformité et la souveraineté des données ne s’arrêtent pas au fonctionnement, elles se jouent aussi à la sortie. Un plan de sortie est plus que « nous pouvons exporter ». Il comprend :

• Export de données : formats, exhaustivité (incl. métadonnées, journaux d’audit), fréquence, automatisation.
• Identités et autorisations : comment les rôles, groupes et structures d’autorisations seront‑ils migrés ou recréés ?
• Interfaces : quelles intégrations dépendent du système (ERP, DMS, IAM, BI) ? Comment sera effectuée la bascule ?
• Délais : Combien de temps les données RESTent‑elles disponibles après résiliation ? Comment est effectuée la suppression vérifiable ?
• Dépendances : Workflows propriétaires, modèles de données, rapports, automatisations.

Si ces points ne sont pas garantis contractuellement et techniquement, le Vendor Lock‑in n’est pas un « ressenti », mais un blocage concret de la migration.

Liste de contrôle pour les achats (RFP) : comparer SaaS vs. On‑Premise de manière auditable

La liste de contrôle suivante est délibérément rédigée de façon à pouvoir être intégrée dans un RFP, une liste de Due‑Diligence ou une fiche d’évaluation interne.

A) Données et protection des données

• Quelles catégories de données sont traitées ? Existe‑t‑il des fonctions de classification/étiquetage des données ?
• Où se déroulent le traitement et le stockage (régions) ? Existe‑t‑il une garantie contraignante sur la résidence des données ?
• Comment les sous‑processeurs sont‑ils divulgués ? Y a‑t‑il des notifications préalables, un droit d’opposition, des droits de sortie ?
• Comment les demandes de suppression sont‑elles exécutées et prouvées (incl. sauvegardes, répliques, logs) ?
• La solution prend‑elle en charge les droits des personnes concernées (droit d’accès, suppression, export) dans un délai praticable ?

B) Sécurité et contrôle d’accès

• Support pour SSO (p. ex. SAML/OIDC) et MFA, y compris pour les accès administrateur et les accès API ?
• Modèle de rôles : principe du moindre privilège, rôles personnalisés, rôles admin séparés, comptes Break‑Glass (accès d’urgence) avec journalisation ?
• Chiffrement : en transit / au repos ; options pour BYOK/HYOK ; rotation des clés ; auditabilité des opérations sur les clés ?
• RESTrictions réseau et d’accès : IP‑allowlisting, connectivité privée, isolation des locataires ?

C) Audit, journalisation et preuves

• Quels logs d’audit sont disponibles (actions admin, accès aux données, exports, événements d’authentification) ?
• Quelle est la durée de conservation des logs et peuvent‑ils être exportés (intégration SIEM) ?
• Quels rapports d’audit indépendants sont disponibles (p. ex. rapports SOC) et quelle est leur actualité ?
• Comment le change‑management est‑il documenté (release notes, fenêtres de maintenance, options de rollback) ?

D) Exploitation, résilience et support

• RTO/RPO définis, fréquence des sauvegardes, tests de RESTauration, documentation justificative ?
• Incident‑response : interlocuteurs, escalade, délais de notification, assistance forensique, post‑mortems ?
• SLA : disponibilité, horaires de support, temps de réponse, priorisation, logique d’indemnisation ?
• Dépendances : fournisseurs IAM, livraison d’e‑mail, DNS, limites de débit d’API, fenêtres de maintenance ?

E) Sortie, portabilité, fin de contrat

• Exports standardisés (données + métadonnées + audit trail), documentés et testables régulièrement ?
• Délais et conditions en cas de résiliation : accès aux données, export, suppression, coûts ?
• Support à la migration : documentation technique, stabilité des interfaces, fenêtres de migration ?

Modèles types : exigences minimales en tant que texte de politique

Pour éviter que les exigences n’existent uniquement « dans la tête », un bref module de politique copiable est utile. Il est volontairement générique et doit être adapté à votre organisation.

POLICY: Auswahl und Betrieb von SaaS- und On-Premise-Lösungen mit Schutzbedarf „vertraulich“ oder höher

1. Identität & Zugriff
- Administrativer Zugriff erfordert MFA und ist personenbezogen (keine geteilten Konten).
- Rollen und Berechtigungen folgen dem Least-Privilege-Prinzip und werden mindestens quartalsweise rezertifiziert.
- Notfallzugänge (Break-Glass) sind dokumentiert, zeitlich begrenzt und vollständig protokolliert.

2. Daten & Schlüssel
- Daten werden in Transit und at REST verschlüsselt.
- Schlüsselmanagement ist dokumentiert (Rotation, Sperrung, Recovery). Wo möglich, sind kundenseitig kontrollierte Schlüssel zu bevorzugen.

3. Logging & Audit
- Sicherheitsrelevante Ereignisse (Auth, Admin-Aktionen, Exporte, Löschungen) sind revisionssicher protokolliert.
- Logs sind exportierbar und werden zentral korreliert (SIEM oder äquivalent).

4. Resilienz
- RTO/RPO sind festgelegt und durch regelmäßige RESTore-Tests nachgewiesen.
- Incident-Prozesse (Meldung, Eskalation, Kommunikation) sind vertraglich und organisatorisch geregelt.

5. Exit
- Datenexport und Löschung bei Vertragsende sind technisch möglich, dokumentiert und vertraglich zugesichert.
- Der Exit-Plan wird vor Vertragsabschluss bewertet und mindestens jährlich überprüft.

Évaluer coûts et risques de manière réaliste : le TCO rencontre l’effort de conformité

La question des coûts est souvent réduite aux coûts de licence. Pour les exigences de conformité et de souveraineté des données, il est toutefois déterminant de savoir combien d’effort est consacré aux contrôles et à la justification. Blocs de coûts typiques :

• SaaS : licences, modules additionnels (sécurité/conformité), intégration au SIEM, options d’exportation de données/sauvegarde, support Enterprise, efforts contractuels et d’audit, éventuels coûts pour des options de chiffrement contrôlées côté client.
• On‑Premise : matériel/virtualisation, stockage/sauvegarde, segments réseau, durcissement, fenêtres de correctifs, disponibilité 24/7, monitoring/SIEM, effort en personnel pour l’exploitation et la documentation, tests de RESTauration, gestion du cycle de vie.

Une erreur fréquente : on considère souvent l’On‑Premise comme « gratuit » avec les équipes existantes, alors que le SaaS est perçu comme « cher ». Dans les audits, ce qui compte, c’est si l’exploitation et la documentation sont réellement assurées. Si On‑Premise implique que les correctifs, la rotation des clés ou les tests de RESTauration sont omis pour des raisons de capacité, le risque de non-conformité devient rapidement un sujet de direction.

Modèles de décision typiques et options hybrides pertinentes

La pratique est rarement binaire. Des modèles robustes émergent souvent de combinaisons :

• SaaS avec contrôle strict de l’identité et des données : SSO/MFA obligatoires, modèle de rôles RESTrictif, export SIEM, règles claires sur les sous-traitants, résidence des données fixée contractuellement.
• On‑Premise pour les processus cœur à haute sensibilité : lorsque la souveraineté des données et la proximité d’intégration priment et que vous disposez de la maturité opérationnelle requise.
• Hybride : les données sensibles RESTent sur site (par ex. dans un stockage interne), le SaaS fournit le workflow/UX ; les interfaces sont conçues de manière à permettre la minimisation des données et la pseudonymisation.

Pour la phase d’acquisition, il est important : l’hybride n’est pas une échappatoire à la responsabilité, mais augmente la complexité d’intégration et de gouvernance. En revanche, il peut découper les flux de données de façon à réduire les risques de conformité.

Note de décision : modèle de scoring avec acceptation du risque

Pour les décisions en comité, un scoring simple aide, sans prétendre que tout soit mesurable avec précision. Une échelle 0–3 par dimension est recommandée (0 = non rempli, 3 = totalement rempli) plus des critères obligatoires. Dimensions généralement pondérées en matière de conformité/souveraineté des données :

• Résidence des données et contrôle des sous‑processeurs
• Maîtrise des clés (BYOK/HYOK) et preuves de chiffrement
• Auditabilité (logs, rapports, rapports d’audit indépendants)
• Identité et accès (capacité SSO/MFA/PAM)
• BCP/DR (RTO/RPO, preuves de RESTauration)
• Capacité de sortie (exportation, suppression, portabilité)
• Capacité opérationnelle (ressources, compétences, runbooks, supervision)

Important est l’étape finale : si un modèle est choisi alors que certaines dimensions ne sont pas suffisamment couvertes, il faut une acceptation du risque documentée avec plan d’actions, responsable et échéance. Sans cette discipline, « SaaS vs. On‑Premise » se transformera plus tard en un conflit sur les responsabilités.

Conclusion : le bon choix est celui que vous maîtrisez de manière démontrable

SaaS vs. On‑Premise n’est pas une question de croyance, mais une question de contrôles maîtrisables. Le SaaS peut bien soutenir la conformité et la souveraineté des données si l’identité, le logging, le contrôle des sous‑processeurs, la gestion des clés et la planification de sortie sont clairement réglés. L’On‑Premise peut offrir une souveraineté maximale sur les données et le contrôle, mais exige une maturité en exploitation, documentation, discipline de patching et tests de RESTauration.

Si vous utilisez le cadre décrit ici – contrôles minimaux, RACI, plan de preuves et chapitre de sortie – vous obtiendrez une décision qui ne sonne pas seulement bien lors de l’achat, mais tient aussi en audit et en situation de crise.

Les exigences de conformité sont également importantes pour ce sujet. Le présent article replace ces aspects de manière compréhensible et montre ce qui importe dans la pratique.