Privatim : pas de cloud SaaS international pour données publiques sensibles

Privatim estime que les organes publics ne devraient pas confier des données sensibles ou secrètes à des SaaS internationaux, sauf chiffrement sous clé exclusive.

L’attractivité du cloud public repose sur l’élasticité et les économies d’échelle, mais Privatim rappelle que l’externalisation ne transfère pas la responsabilité : le cadre est posé dans la résolution sur l’externalisation du traitement des données dans le cloud.

Une ligne rouge : données sensibles et secrets, contrôle jugé insuffisant

Le raisonnement de Privatim revient sur un constat technique souvent mal compris : chiffrer “dans le cloud” ne signifie pas automatiquement que le fournisseur ne peut jamais lire les données. La résolution souligne que la plupart des solutions SaaS ne proposent pas encore un chiffrement qui empêcherait réellement le fournisseur d’accéder aux données en clair. Pour un public non initié, la nuance est essentielle. Un service peut chiffrer les échanges réseau et chiffrer les disques, tout en gardant la capacité de déchiffrer lors du traitement, par conception, afin d’offrir recherche, indexation, collaboration ou automatisation.

Ensuite, le texte pointe une fragilité de gouvernance qui dépasse la seule cryptographie : le niveau de transparence offert par des acteurs mondiaux est jugé insuffisant pour permettre à une autorité suisse de vérifier durablement le respect des obligations contractuelles en matière de protection et de sécurité. Cette difficulté ne concerne pas seulement les contrôles ponctuels ; elle touche la réalité quotidienne d’un SaaS : gestion des changements, évolutions de versions, pratiques opérationnelles, engagement et contrôle des collaborateurs, ainsi que la maîtrise des sous-traitants.

À cette opacité s’ajoute un facteur structurel : la capacité de certains fournisseurs à adapter périodiquement et unilatéralement des conditions contractuelles. Même si les contrats initiaux paraissent compatibles avec des exigences publiques, la stabilité dans le temps devient un risque. La résolution traduit cette accumulation en une formule sans ambiguïté : l’utilisation d’applications SaaS s’accompagne d’une perte de contrôle considérable.

Le point le plus politique, au sens de la protection des droits, l’organe public ne peut agir que sur la gravité potentielle, en limitant ce qui sort de son domaine de contrôle. Autrement dit, lorsque l’incertitude sur l’environnement d’exécution est trop forte, l’unique variable réellement maîtrisable reste l’exposition des données.

Enfin, la résolution isole le cas des données soumises à une obligation légale de garder le secret. Ici, le sujet n’est pas seulement “un fournisseur est-il fiable ?”. Il devient “un transfert est-il juridiquement admissible ?”. Le texte rappelle qu’il n’est pas possible de faire appel à tout tiers comme auxiliaire, même si certaines règles pénales imposent aussi aux auxiliaires une obligation de silence. Cette précision dessine un angle mort fréquent : un engagement contractuel de confidentialité ne suffit pas forcément à rendre le transfert licite.

La condition “clé hors d’atteinte” : le chiffrement comme barrière réelle

Au milieu de ces freins, privatim ménage une seule porte d’entrée, très étroite. L’usage de solutions SaaS internationales pour des données personnelles sensibles ou soumises au secret est envisageable uniquement si deux conditions cumulatives sont respectées : les données doivent être chiffrées par l’organe responsable lui-même, et le fournisseur de cloud ne doit pas avoir accès à la clé.

Cette exigence change la nature de la confiance. Tant que le fournisseur détient la clé, il détient la capacité de rendre les données lisibles, que ce soit pour assurer le service, pour répondre à une demande légale dans son pays, ou à la suite d’une compromission. À l’inverse, si la clé reste exclusivement sous contrôle de l’organe public, la donnée hébergée devient, pour le fournisseur, un contenu inexploitable.

Le concept se rapproche du “chiffrement avec sa propre clé” et du principe bring-your-own-key (BYOK). BYOK désigne une approche où la clé cryptographique n’est pas générée, stockée et administrée par le fournisseur, mais par l’organisation cliente. L’objectif n’est pas seulement d’“ajouter du chiffrement” ; il est de conserver la capacité de gouverner la clé : création, stockage, rotation (remplacement périodique), révocation (invalidation), et contrôle strict des accès. Le bénéfice opérationnel est double : réduire l’exposition du contenu en clair hors du périmètre de contrôle, et éviter qu’un changement contractuel, une erreur d’exploitation ou une contrainte externe côté fournisseur ne transforme un hébergement en accès.

Ce cadrage n’efface pas les contraintes fonctionnelles. Beaucoup de services SaaS doivent manipuler des données en clair pour fournir des fonctions avancées. Plus le service est “intelligent” (recherche, tri, corrélation, détection de doublons, automatisation), plus la tension augmente entre fonctionnalités et impossibilité d’accès au contenu. Dans cette logique, l’exigence “clé hors d’atteinte” peut conduire à segmenter les usages : certaines données restent dans un périmètre maîtrisé, d’autres sont envoyées chiffrées de bout en bout côté autorité, ou des traitements sont redessinés pour éviter d’exposer des secrets à un tiers.

Le texte ajoute aussi une dimension extraterritoriale concrète : le CLOUD Act, en vigueur depuis 2018, peut contraindre des fournisseurs américains à fournir des données de clients aux autorités américaines sans suivre les règles de l’entraide judiciaire internationale, y compris lorsque les données sont stockées dans des centres de calculs en Suisse. Dans ce contexte, l’absence d’accès du fournisseur à la clé devient une manière de déplacer le problème : plutôt que de miser sur une localisation géographique, la protection repose sur une impossibilité technique de livrer des données en clair.

Ce que la résolution change dans les arbitrages publics suisses

Le texte invite à renverser une séquence de décision trop fréquente. Le réflexe consiste souvent à choisir d’abord un outil, puis à adapter les processus, puis à découvrir la nature réelle des données impliquées. La résolution pousse à l’inverse : cartographier les types de données et leurs contraintes (sensibilité, secret, exigences légales), analyser les risques dans chaque cas, puis choisir des mesures qui ramènent le risque à un niveau acceptable.

Dans ce cadre, l’arbitrage ne se limite pas à “cloud” contre “pas cloud”. Il devient “quelles données peuvent sortir, dans quelles conditions prouvables, avec quels contrôles, et avec quel niveau d’indépendance vis-à-vis du fournisseur”. La perte de contrôle décrite par privatim n’est pas une abstraction : elle recouvre la capacité réelle à vérifier ce qui se passe, à maîtriser la chaîne de sous-traitance, à anticiper des changements non négociables et à garantir, dans la durée, la conformité à des obligations publiques.

Un angle mort mérite d’être gardé en tête : la condition cryptographique n’est pas un remède universel. Le chiffrement protège le contenu, mais pas nécessairement les métadonnées, la gestion des identités et des accès, la configuration des comptes, ni la qualité des journaux d’audit. Autrement dit, même si le fournisseur ne peut pas lire les fichiers, un incident peut encore exposer des informations périphériques ou provoquer des perturbations de service. La résolution, d’ailleurs, insiste sur des éléments qui ne sont pas réductibles au chiffrement : transparence, contrôle des changements, gestion des sous-traitants, stabilité contractuelle.

Un contrepoint, tout aussi réel, s’impose : des acteurs industriels peuvent offrir une robustesse d’infrastructure et une capacité d’exploitation difficiles à reproduire localement. La résolution ne nie pas l’attractivité du modèle ni les bénéfices d’échelle. Elle place simplement le curseur ailleurs, sur la responsabilité publique, la protection de données sensibles, et la possibilité de démontrer la conformité, même lorsque le fournisseur opère à l’international.

La mise en perspective finale tient dans un principe unique : pour les données personnelles sensibles et les données soumises au secret, la compatibilité avec un SaaS international ne se joue pas sur une promesse de sécurité générique, mais sur une maîtrise cryptographique et une gouvernance qui empêchent l’accès du fournisseur à la clé. À défaut, l’externalisation fait sortir les données d’un domaine contrôlable, alors même que la responsabilité, elle, reste intégralement du côté de l’autorité.

A lire aussi

Face à Microsoft 365, la Suisse s’interroge sur sa souveraineté numérique

Le recours au cloud Microsoft 365 agite les cantons suisses : entre innovation et contrôle, la souveraineté numérique devient un enjeu stratégique.

Lire la suite sur dcod.ch