Sortie des services cloud : restitution, suppression et portabilité des données

Planifier la sortie plutôt que d’agir dans l’urgence

Quitter un service cloud n’efface pas les obligations : selon les directives du PFPDT sur le traitement des données dans le cloud, le prestataire agit généralement en tant que sous-traitant au sens de l’art. 9 LPD, tandis que le client reste responsable. Il doit veiller à ce que les traitements effectués pour son compte soient conformes à la protection des données et à ce que les droits des personnes concernées ne soient pas lésés par cette externalisation. La sortie constitue donc un projet à part entière avec un calendrier précis, et non une simple résiliation ajoutée après coup.

Cette répartition des rôles détermine ce qui doit être récupéré : non seulement les données téléversées soi-même, mais tout ce qui a été traité pour le compte du client – y compris les stocks détenus par les sous-traitants. Le PFPDT cite comme utilisations typiques du cloud la collaboration en ligne telle qu’Office 365, les outils de gestion en ligne pour les adresses e-mail dans les newsletters ou le service clientèle, les systèmes CRM en ligne, le téléversement de vidéos sur des plateformes de streaming et le stockage de fichiers sur un serveur accessible via Internet.

Planifiez à rebours à partir des dates contractuelles : le délai de résiliation et la fin du contrat déterminent le temps disponible pour l’exportation, la vérification et les livraisons complémentaires. Pour chaque phase de la période de transition, il convient de définir qui est responsable – le secteur spécialisé pour l’exhaustivité fonctionnelle, l’informatique pour l’exportation et l’importation, le conseil en protection des données pour l’évaluation, et la direction générale pour la signature du contrat.

Il faut également fixer les échéances auxquelles les engagements du prestataire doivent être tenus. Sans cette organisation, les accès durant la phase de transition s’écoulent sans que personne ne vérifie les données entrantes.

Les bases légales pertinentes sont la LPD du 25 septembre 2020 (RS 235.1) et, le cas échéant, le RGPD. L’art. 9 LPD régit le sous-traitement ; les personnes concernées ont, selon le droit applicable, un droit d’accès ainsi qu’un droit à l’effacement et à la limitation du traitement. Ces droits doivent être respectés jusqu’à la confirmation de l’effacement.

Bases légales et niveau de décision dans la protection des données suisse

Savoir quelles données se trouvent réellement dans le cloud

Établissez un inventaire par service et distinguez les catégories de données et les groupes de personnes concernées. Les catégories issues des déclarations de confidentialité servent de repères : données de base et de contact, données de contenu, données contractuelles, données d’utilisation, données méta, de communication et de procédure ainsi que les données journalisées. Sont généralement concernés les utilisateurs, les employés, les clientes et clients, les partenaires de communication ainsi que les partenaires commerciaux et contractuels. Celui qui ne remplit pas ces deux axes ne saura pas à la fin si la restitution est complète.

Recensez pour chaque catégorie le lieu de stockage et tous les acteurs impliqués : système principal, index d’analyse et de recherche, pièces jointes dans les données de support et de tickets, environnements de test et de démonstration ainsi que les copies de sauvegarde. Le PFPDT identifie comme points centraux de toute utilisation du cloud le recours à des sous-traitants et sous-sous-traitants, la sécurité du traitement des données et le transfert de données personnelles vers des pays tiers – ces trois points doivent figurer dans l’inventaire. Notez quel sous-sous-traitant traite quelle catégorie ; son effacement ne se fait pas automatiquement avec celui chez le prestataire principal.

Complétez pour chaque service les possibilités d’exportation : existe-t-il une exportation complète et lisible par machine, ou seulement des vues à l’écran et des impressions individuelles ? Quels champs, pièces jointes et métadonnées contient-il, et à quelle fréquence peut-il être généré ? Le résultat est un tableau indiquant le service, la catégorie de données, le groupe de personnes concernées, le lieu de stockage, le sous-sous-traitant impliqué, le format d’exportation et la responsabilité. Sans cette vue d’ensemble, toute demande de restitution reste incomplète, car aucune comparaison entre le théorique et la réalité n’est possible.

Notez pour chaque service le format d’exportation : CSV, JSON et XML sont des formats ouverts et lisibles par machine ; Parquet est un format de fichier ouvert, orienté colonne, pour les grands volumes de données. Exigez un remplissage complet des champs et des métadonnées, pas seulement des vues PDF. Le format doit figurer dans le tableau à côté de la possibilité d’exportation et de la responsabilité.

Régler la restitution et l’effacement avant la résiliation

Fixez par écrit la restitution et l’effacement avant la résiliation ; un engagement pris après la résiliation prononcée est plus difficile à faire respecter. Il convient de régler : le format de la remise (lisible par machine et complet, y compris les métadonnées, les pièces jointes et les liens), l’étendue exacte (catégories de données, période, sous-sous-traitants), le délai de remise, les droits d’accès durant la phase de transition ainsi que les coûts de la restitution. Le PFPDT exige de l’utilisateur du cloud qu’il s’assure et sécurise contractuellement le respect des exigences du sous-traitement selon l’art. 9 LPD ; la clause de restitution et d’effacement en fait partie.

L’effacement comprend quatre indications : la date limite d’effacement après achèvement de la restitution ; les données concernées (données de production, copies de sauvegarde, données journalisées, copies intermédiaires et de test) ; la date limite pour recevoir une confirmation écrite ; et l’inclusion expresse des sous-sous-traitants. Précisez également qui, côté client, vérifie la restitution, selon quels critères et dans quel délai les défauts sont signalés, ainsi que les noms des interlocuteurs des deux parties pour les livraisons complémentaires.

Clarifiez avant la conclusion si l’utilisation était ou est encore liée à une communication de données à l’étranger. Le PFPDT souligne qu’avant toute communication à l’étranger, il faut vérifier si elle satisfait aux exigences légales. Cette vérification vaut jusqu’à l’effacement définitif, pas seulement pour l’exploitation : tant que les données se trouvent chez le prestataire ou ses sous-sous-traitants, la communication persiste.

Restitution des données : ce qui arrive effectivement

Vérifiez les données livrées en trois étapes. Premièrement, l’exhaustivité : le nombre d’enregistrements et de fichiers ainsi que la période couverte correspondent-ils à l’inventaire ? Toutes les catégories de données et tous les groupes de personnes concernées sont-ils inclus ? Deuxièmement, la lisibilité : le format peut-il être ouvert sans logiciel supplémentaire ? L’encodage, les formats de date et de nombres ainsi que les fuseaux horaires sont-ils cohérents ? Troisièmement, l’attribution : les métadonnées, les pièces jointes et les liens sont-ils conservés, permettant d’attribuer chaque enregistrement à la bonne personne concernée ?

Fournissez la preuve par échantillonnage et un test d’importation : injectez des enregistrements sélectionnés dans le système cible et comparez-les avec l’original. Un tel test révèle plus fiablement les pertes de champs, les relations manquantes et les pièces jointes non transférées qu’une simple inspection visuelle du fichier d’exportation. Documentez pour chaque catégorie de données ce qui a été repris et ce qui manque.

En cas de restitution incomplète ou tardive : signalez les défauts par écrit en vous référant au délai et à l’étendue convenus, exigez une livraison complémentaire avec une nouvelle date et ne terminez la phase de transition qu’après vérification de cette livraison. Si la restitution tarde, les demandes des personnes concernées doivent néanmoins pouvoir être traitées. Selon le droit applicable à la protection des données – en Suisse la LPD du 25 septembre 2020 (RS 235.1), complétée le cas échéant par le RGPD – les personnes concernées disposent de droits tels que l’accès, l’effacement et la limitation du traitement ; tant que de telles demandes peuvent arriver, un accès aux stocks non encore restitués est nécessaire.

Vérifiez le format : CSV, JSON, XML et Parquet sont des formats ouverts. Les fichiers Parquet contiennent un schéma explicite ainsi que des métadonnées sur les types de données ; cela permet de vérifier automatiquement les types de champs et l’exhaustivité.

Formats ouverts vs propriétaires pour l’exportation de données

Un effacement qui atteint aussi les copies de sauvegarde

Un concept d’effacement liste chaque endroit où se trouvent les données du service et assigne à chaque lieu un délai d’effacement et une instance responsable : base de données de production, index de recherche et d’analyse, pièces jointes dans les données de support et de tickets, copies intermédiaires et de test, fichiers d’exportation côté client ainsi que les copies de sauvegarde. Il est décisif que les sous-sous-traitants soient listés individuellement ; leur effacement ne découle pas automatiquement de celui chez le prestataire principal.

Les copies de sauvegarde et les données journalisées nécessitent une attention particulière. Pour les copies de sauvegarde, le délai d’effacement peut différer de celui des données de production, car les copies ne sont écrasées qu’avec le prochain cycle de sauvegarde ; il faut donc noter jusqu’à quand les données sont réellement supprimées, et pas seulement à partir de quand elles ne sont plus activement utilisées. Les données journalisées doivent être traitées séparément : elles peuvent rester plus longtemps pour des raisons de traçabilité ou en raison d’obligations propres de conservation ; cela doit figurer explicitement dans le concept d’effacement.

Exigez une confirmation écrite d’effacement avec la date, les catégories de données recensées et les sous-sous-traitants impliqués. Tant qu’elle fait défaut, la responsabilité incombe au client : en tant que responsable, il répond du traitement conforme à la protection des données – y compris pour les traitements effectués pour son compte. Précisez dans le concept comment gérer les données nouvelles survenant durant la phase de transition, par exemple les signalements de support concernant les stocks exportés.

Portabilité : emporter les données plutôt que de simplement les copier

Clarifiez avant l’exportation dans quel format les données pourront être réutilisées dans le système cible. Exigez des formats ouverts, lisibles par machine, et un remplissage complet des champs ; clarifiez la gestion des relations et des ID d’objets, des pièces jointes et des fichiers binaires, ainsi que l’encodage, le format de date et le fuseau horaire. Une vue PDF est une information, mais pas un outil de travail pour la réutilisation.

Testez la portabilité par une importation dans le système cible avant de confirmer la résiliation : établissez le mappage des champs, alignez les champs obligatoires du système cible, documentez les champs non transférables et les valeurs par défaut. Le test montre aussi si le volume de données peut effectivement être transféré dans le temps prévu – pour les grands stocks, cela détermine le calendrier.

Distinguez la portabilité du service du droit des personnes concernées à leurs propres données. Selon le droit applicable, les personnes concernées ont un droit d’accès ainsi qu’un droit à l’effacement et à la limitation du traitement ; la déclaration de confidentialité d’un service en informe. Le responsable doit pouvoir respecter ces droits même après la sortie. L’exportation technique du prestataire ne couvre pas cela : elle englobe généralement l’ensemble du stock, tandis qu’une demande ne concerne que les données d’une personne concernée – pour cela, il faut après la sortie un archivage propre, consultable dans le système cible.

La portabilité cloud signifie déplacer applications, données et charges de travail sans développement majeur nouveau et sans perte de données d’un environnement cloud à un autre. Cela inclut des formats de données ouverts comme JSON, XML et CSV ainsi que des API ouvertes.

Contrôlez les interfaces : des API ouvertes comme REST ou GraphQL plutôt que des points de terminaison propriétaires ; authentification via des standards comme OAuth, SAML ou OpenID. Les applications conteneurisées avec Docker ou Kubernetes facilitent le déplacement.

Pour les grands volumes de données, le format ouvert orienté colonne Parquet, qui transporte schéma et métadonnées, est approprié. Clarifiez avant l’exportation si le système cible peut traiter CSV, JSON, XML ou Parquet.

Chiffrement et clés sous son propre contrôle

La Conférence des responsables suisses de la protection des données (Privatim) stipule dans sa résolution sur l’externalisation du traitement des données dans le cloud : pour les organes publics, l’utilisation de solutions SaaS de prestataires internationaux n’est admissible que si les données personnelles particulièrement sensibles sont chiffrées par l’organe lui-même. Il en va de même pour les données personnelles soumises à une obligation légale de secret. Le prestataire cloud ne doit avoir aucun accès à la clé.

La résolution a été adoptée le 18 novembre 2025 et publiée le 24 novembre 2025.

En pratique, cette exigence rencontre des limites. Selon la résolution, la plupart des services cloud ne permettent pas une utilisation pertinente avec un chiffrement de bout en bout. Pour les services utilisables de manière pertinente avec un chiffrement de bout en bout continu, il est souvent impossible d’empêcher totalement le prestataire d’accéder aux clés des utilisateurs. Pour les services internationaux comme Amazon Web Services (AWS), Google ou Microsoft 365, il ne reste essentiellement aux organes publics que l’utilisation en tant que pur stockage en ligne.

Pour la sortie, il en découle : clarifiez avant la restitution quelles données sont stockées chiffrées, qui détient les clés et sous quelle forme les données sont remises – chiffrées avec le matériel de clé fourni ou déchiffrées via un canal sécurisé. Sauvegardez et vérifiez les clés avant le dernier accès au service ; sans clés, les données récupérées ne sont plus exploitables. Définissez également qui, dans l’entreprise, a accès aux clés et ce qui advient en cas de perte ou de changement de la personne responsable des clés.

Pourquoi un emplacement de serveur en Europe ne suffit pas

Le PFPDT souligne que lors de l’utilisation de services cloud, il faut vérifier avant toute communication de données à l’étranger si elle satisfait aux exigences légales. Cette vérification fait partie de la sortie comme de l’entrée : elle concerne toutes les données qui se trouvent encore chez le prestataire ou ses sous-sous-traitants jusqu’à la confirmation de l’effacement.

Un emplacement de serveur en Europe ne suffit pas pour cela. Un article spécialisé sur la sécurité cloud en Suisse porte dans son titre l’affirmation « Cloud en Europe : aucune protection contre l’accès US » et souligne que la sécurité cloud en Suisse signifie plus qu’un simple emplacement de serveur européen. Pour la sortie, cela signifie : obtenir par écrit les indications sur la communication de données – siège et société mère du prestataire, siège des sous-sous-traitants, lieu du traitement, base légale de la communication – et ne pas les déduire de l’emplacement du serveur.

Pour les organes publics, la barre est plus haute, car la plupart de leurs données sont soumises au secret de fonction et donc à une obligation légale de secret. La résolution de Privatim précise que les organes publics peuvent externaliser le traitement à des tiers, mais doivent assurer le maintien de la protection des données et de la sécurité de l’information ; pour les données personnelles particulièrement sensibles ou soumises à une obligation légale de secret, elle exige le chiffrement par l’organe lui-même. Lors de la sortie, il faut donc documenter où se trouvent les données jusqu’à l’effacement et quelles possibilités d’accès existent pour des tiers durant cette période.

Avantages et risques liés à un emplacement de serveur en Europe

Documenter l’offboarding

À l’issue du processus, les documents suivants devraient être disponibles : un protocole de restitution avec la date, les catégories de données remises, les formats et supports ainsi qu’une mention de vérification avec échantillonnage, test d’importation et d’éventuels défauts avec les livraisons complémentaires.

Doivent également figurer une confirmation écrite d’effacement avec date et étendue, la confirmation que les sous-sous-traitants ont été inclus, et la preuve de la sauvegarde et de la garde des clés de chiffrement. Sans ces preuves, il sera impossible ultérieurement de prouver ni aux personnes concernées ni à une autorité de surveillance quand quelles données ont été récupérées et effacées.

Adaptez les registres internes : retirez le service et les sous-sous-traitants du registre des traitements ou du registre des contrats, ou marquez-les comme terminés, redéfinissez les délais de conservation et d’effacement pour les stocks récupérés et ajustez les droits d’accès dans le système cible. Supprimez les comptes, clés API, jetons et utilisateurs de service du service terminé ; sinon, des accès subsistent que personne ne gère plus.

Vérifiez enfin la communication externe. Si le service est mentionné dans la déclaration de confidentialité ou dans une liste des prestataires et services utilisés, l’entrée doit être adaptée. Les obligations d’information et le traitement des demandes d’accès et d’effacement des personnes concernées continuent dans le système cible après la sortie ; définissez qui en est responsable et comment les stocks récupérés peuvent être recherchés.