Régler la restitution et la suppression des données lors de la sortie d'un SaaS

Pourquoi il faut régler tôt la restitution et la suppression des données

Les contrats SaaS régissent l'étendue des prestations, la disponibilité, les droits d'utilisation, les mises à jour, le support, la responsabilité et la résiliation. Selon Lezzi Legal (Zurich), les questions relatives à l'utilisation des données, à l'exportation des données et à la sortie sont tout aussi importantes. Celui qui ne clarifie la restitution et la suppression qu'au moment de la résiliation négocie dans une phase où le fournisseur contrôle les accès.

Lors de la sortie, il convient de distinguer deux catégories de données : les données personnelles, soumises aux obligations en matière de protection des données, et les données non personnelles. Selon MME, l'EU Data Act s'applique parallèlement au RGPD et couvre également les données machine ou produit non personnelles. Une sortie peut ainsi déclencher l'application de deux cadres réglementaires.

L'appréciation juridique dépend de l'architecture technique : quelles données sont traitées, quels fournisseurs sont impliqués, comment les systèmes communiquent et quelle partie contrôle les données et les fonctions (Lezzi Legal). Les clauses relatives à l'utilisation des données, à l'exportation et à la sortie doivent donc être adaptées pour chaque produit aux flux de données réels, et non reprises comme texte standard.

Les produits SaaS évoluent plus vite que les contrats : les fonctionnalités, les modèles de prix, les intégrations et les dépendances techniques s'adaptent en continu. Selon Lezzi Legal, la documentation juridique doit pouvoir évoluer avec le produit et ne pas devoir être reconstruite à chaque ajustement technique.

Pour les données personnelles, la législation suisse sur la protection des données doit être prise en compte (PFPDT). Pour les entreprises SaaS ayant un lien avec le marché de l'UE, l'EU Data Act s'applique selon MME parallèlement au RGPD, y compris pour les données machine ou produit non personnelles (MME).

Recenser le patrimoine de données et les dépendances avant la résiliation

Avant la résiliation, un inventaire doit être établi : données centrales de l'application, rapports, sorties OCR, données de contacts et de calendrier, clés API et Webhooks. Pour chaque élément, il faut indiquer s'il est généré exclusivement dans le SaaS ou s'il alimente également d'autres systèmes. Seule cette distinction montre quelles données un export depuis le SaaS peut couvrir et lesquelles doivent être sauvegardées séparément.

Les extensions d'un logiciel ERP et d'agence montrent des dépendances typiques : la reconnaissance OCR lit directement les pièces justificatives, marque automatiquement en jaune les données remplies et apprend avec chaque nouvelle pièce du même fournisseur. Via CardDAV, les données professionnelles de contact concernant les entreprises, le personnel et les personnes de contact sont récupérées, gérées centralement dans l'application et affichées de manière synchronisée sur les appareils. L'activation de la connexion Zapier génère une clé API spécifique au compte, permettant de connecter d'autres outils business basés sur le web. Pour le système téléphonique 3CX, une clé API est enregistrée depuis la zone de profil (MOCO).

Les extensions peuvent avoir leur propre logique de fin. Vérifiez donc pour chaque connexion quand elle prend fin, qui désactive l'accès et si un export en dépend. Planifiez la sauvegarde avant qu'une fonctionnalité ou une interface ne soit désactivée.

Outre les flux de données, les clés doivent être recensées : qui détient les clés API, vers quels systèmes cibles pointent les Webhooks, et quels accès doivent être révoqués lors de la sortie. Sans ce répertoire, des connexions actives vers des systèmes tiers subsistent après la résiliation.

Les états appris font également partie de l'inventaire : l'OCR apprend avec chaque nouvelle pièce du même fournisseur, et les données remplies automatiquement sont marquées en jaune (MOCO). Ces attributions et marquages constituent des patrimoines propres qui doivent être transférés lors de la restitution ou supprimés par la suite.

Procédure avant la sortie d'un SaaS : de la collecte des données à la migration

Clause de sortie : articuler restitution, suppression et migration

La clause de sortie doit être articulée avec les autres règles de résiliation : les délais de résiliation, les dates de résiliation, la durée et le renouvellement automatique ont un impact direct sur le temps disponible pour l'export et la migration. Celui qui règle la sortie séparément crée des délais qui ne correspondent pas.

Si la prestation convenue contractuellement relève de l'EU Data Act, la conception n'est plus libre. Selon MME, les durées contractuelles typiques de 12 à 24 mois seront interdites à l'avenir dès que la prestation tombe sous le coup de la loi. Alignez donc la durée, la résiliation et la remise sur les prescriptions applicables au contrat concret (MME).

La clause doit couvrir trois prestations : la restitution des données, la suppression après l'expiration d'éventuelles obligations de conservation et le soutien lors de la migration vers un autre fournisseur. Définissez pour chaque prestation l'étendue, le délai, la réglementation des coûts et l'obligation de collaboration. En cas de lien avec l'UE, l'applicabilité de l'EU Data Act doit être vérifiée avant de traiter une obligation de soutien comme légalement impérative.

La durée doit déjà être indiquée dans l'offre : selon les CGV de Libra AI, l'offre doit mentionner la durée de l'abonnement avec l'indication du renouvellement automatique. Les délais de sortie doivent être alignés sur ce renouvellement.

Selon les CGV de Libra AI, l'offre comprend en outre la version choisie, le nombre d'utilisateurs, le prix, les données de contact et de paiement, la date de début d'utilisation et l'indication si une version d'essai gratuite ou payante est incluse. Les délais de sortie ne peuvent être calculés que lorsque ces indications sont disponibles.

Les obligations post-contractuelles doivent figurer explicitement dans la clause. L'expertise Cloud pour la ville de Zurich contient une disposition selon laquelle une obligation subsiste même après la fin du contrat. Les obligations de restitution et de suppression doivent donc être rédigées de manière à survivre à la fin du contrat.

Liste de contrôle : Points importants pour la clause de sortie dans le contrat SaaS

Restitution des données : convenir du format, du délai et de l'accès à l'export

Pour chaque type de données, il faut définir sous quelle forme, via quel canal et jusqu'à quand elles sont restituées. Les canaux possibles sont l'API, les Webhooks et les exports standards. La connexion API dépend dans la pratique de clés spécifiques au compte – lors de la connexion Zapier par exemple, l'activation génère une clé API spécifique au compte (MOCO). La clause doit donc régir quelles clés restent valables pendant la fenêtre d'export, qui les révoque et ce qui s'applique si la clé est bloquée avant l'achèvement de la restitution.

Il ne s'agit pas seulement de restituer ce qui se trouve dans la base de données de l'application. Les données récupérées via CardDAV sont affichées de manière synchronisée sur les appareils selon la description du fournisseur, sur lesquels les contacts ont été ajoutés. Un export depuis le SaaS ne couvre pas automatiquement ces copies sur les appareils terminaux ; il convient donc de clarifier contractuellement qui les supprime après la sortie.

La concrétisation comprend : les responsabilités des deux parties, les délais de remise, le format de livraison, les indications sur l'exhaustivité (par exemple les jeux de données reconciliés) et une phase de réception durant laquelle le client peut vérifier l'export. Il faut également régir ce qui advient en cas d'export échoué ou incomplet et jusqu'à quand l'accès est maintenu après la remise. Les prestations peuvent prendre fin à court terme – l'extension OCR peut être arrêtée à tout moment sans délai de résiliation –, c'est pourquoi l'export doit être placé dans une fenêtre temporelle avec un accès sécurisé.

Formulation type pour la restitution : « Le fournisseur met à disposition les données clients désignées dans [répertoire des données] jusqu'au [délai de restitution] après [déclencheur] de manière complète en [format convenu] via [canal de remise]. Le client peut vérifier l'exhaustivité jusqu'au [délai de vérification] ; le fournisseur comble les lacunes constatées jusqu'au [délai de grâce]. » Inscrivez une indication contraignante pour chaque espace réservé ; « export standard » seul ne désigne ni le format cible ni l'étendue.

La granularité fait également partie de la spécification du format : la sortie OCR peut être lue globalement comme une seule position ou comme des positions individuelles (MOCO). La clause devrait indiquer quel niveau le client nécessite pour la poursuite de l'utilisation.

Lors de la connexion 3CX, le fichier de configuration est téléchargé dans le système téléphonique et la clé API MOCO est enregistrée dans le profil sous Intégrations (MOCO). De tels accès ne doivent être révoqués que lorsque l'export est achevé et accepté.

Régler la suppression et la conservation avec preuve

La clause de suppression doit couvrir quatre catégories : les données personnelles, les données produit et machine, les sauvegardes ainsi que les copies chez les sous-traitants et autres prestataires de services utilisés. Pour chaque catégorie, il faut déterminer le délai de suppression, les exceptions (par exemple les obligations légales de conservation) et la preuve attestant la suppression. Lors de la migration de données produit, des exigences supplémentaires du RGPD peuvent s'appliquer si des données personnelles sont concernées (MME).

La chaîne d'instructions doit être sécurisée contractuellement. Dans les CGV de Libra AI, le sous-traitant s'engage à informer immédiatement le client si une instruction viole, selon lui, le droit applicable en matière de protection des données. Une instruction de suppression qui entre en conflit avec des obligations de conservation déclenche ainsi une obligation d'information – la procédure à cet effet (interlocuteur, délai, forme) devrait être définie avant la sortie.

Comme preuves, il faut prévoir une confirmation écrite de suppression avec date, une liste des destinataires de l'ordre de suppression et des informations sur le cercle des sous-traitants. Il faut également régir sous quelle forme ces confirmations sont délivrées et jusqu'à quand elles doivent être disponibles après l'achèvement de la suppression.

Formulation type pour la suppression : « Après l'expiration de la phase de restitution et de vérification convenue, le fournisseur supprime les données des environnements désignés dans [systèmes et copies], dans la mesure où aucune obligation nommée dans [obligation de conservation et jeux de données] n'exige leur conservation. Le fournisseur transmet jusqu'au [délai de preuve] une confirmation écrite avec la date de suppression et les destinataires enregistrés. » Concrétisez les espaces réservés par catégorie de données ; en cas d'exception, nommez les données concernées et le motif.

Cette obligation de conservation concerne les documents commerciaux mentionnés, et non globalement toutes les données SaaS. En cas de lien avec l'UE, l'EU Data Act s'applique selon MME parallèlement au RGPD et aussi pour les données machine ou produit non personnelles ; lors de la migration de données produit, des exigences du RGPD peuvent s'appliquer si des données personnelles sont concernées (MME).

Pour les données personnelles, la législation suisse sur la protection des données doit être prise en compte ; le Préposé fédéral à la protection des données et à la transparence (PFPDT) n'a plus de compétence sanctionnaire selon le nouveau droit (PFPDT). Conformément à l'art. 958f CO, les livres de commerce, les pièces comptables ainsi que les rapports de gestion et de révision doivent être conservés pendant dix ans (BDO).

Délais juridiques et exigences importants lors de la sortie d'un SaaS

Suppression des données après la fin du contrat : déroulement de la procédure avec preuve

Sécuriser contractuellement la migration vers le nouveau fournisseur

MME décrit comme une opportunité de la loi sur les données qu'il est devenu plus facile de migrer sa propre infrastructure cloud vers un autre fournisseur. Pour la clause de sortie, il reste à définir quelles données et formats le fournisseur met à disposition, combien de temps dure le soutien et quelle collaboration le client doit fournir. Nommez les prestations et les limites de manière si concrète que les parties puissent planifier la migration.

Les limites de l'aide doivent être tracées contractuellement : quelles données et formats, quelle période, quels interlocuteurs, quelle collaboration du client. Sans une telle précision, il reste ouvert ce que « soutenir activement » comprend dans le cas concret.

L'application doit être prise au sérieux. MME souligne que les entreprises qui ne mettent pas en œuvre ces exigences dans leurs contrats doivent s'attendre à des actions en justice de la part de concurrents et risquent des amendes élevées, comparables aux sanctions selon le droit européen de la protection des données. Déjà aujourd'hui, certains clients SaaS adaptent leurs contrats et, dans certains cas, aussi leurs modèles commerciaux et de vente.

Harmoniser contrat, CGV, DPA et documentation sur la protection des données

Pour les modèles standardisés, le contrat SaaS, les CGV, les niveaux de service, le contrat de traitement des données (DPA) et la documentation sur la protection des données devraient être harmonisés (Lezzi Legal). Si les règles de sortie divergent dans un document et les règles de conservation ou de suppression dans un autre, des contradictions apparaissent, qui seront interprétées contre le fournisseur en cas de litige.

La hiérarchie décide quel document s'applique. Les CGV de Libra AI prévoient que les conditions générales divergentes du client ne s'appliquent pas. Il en va autrement uniquement si le fournisseur consent expressément par écrit à leur application. Les CGV font partie intégrante de tous les contrats ainsi que de toutes les prestations et offres futures. Celui qui fixe les règles de sortie dans une annexe ou dans le DPA doit donc vérifier si ces documents priment sur les CGV.

En pratique, cela signifie : mener les règles de sortie de manière complète à un seul endroit, y renvoyer depuis tous les autres documents et les suivre lors de chaque modification du produit. Comme les fonctionnalités, les modèles de prix et les intégrations changent en continu, la documentation doit, selon Lezzi Legal, être conçue de manière à croître avec le produit.

Selon les CGV de Libra AI, la langue faisant foi pour la conclusion du contrat est l'allemand ; les traductions servent uniquement à titre d'information, et en cas de contradiction, la version allemande prévaut. Les règles de sortie dans une annexe traduite peuvent donc passer au second plan par rapport à la version allemande.

Droit suisse et touches européennes lors de la sortie d'un SaaS

L'EU Data Act (règlement (UE) 2023/2854 établissant des règles harmonisées pour un accès équitable aux données et une utilisation équitable des données) s'applique depuis son entrée en vigueur mi-septembre 2025. Pour les entreprises suisses SaaS et IoT actives sur le marché de l'UE, il a créé un nouvel environnement réglementaire (MME, « EU Data Act : Ce que les entreprises suisses SaaS et IoT doivent faire maintenant », 12 janvier 2026).

Avant l'adaptation du contrat vient la vérification de l'applicabilité : tous les modèles SaaS ne tombent pas sous le règlement, même si des affirmations partiellement contradictoires circulent à ce sujet (MME). Vérifiez donc le produit concret, la prestation convenue contractuellement et le lien avec le marché de l'UE avant de reprendre des clauses Data Act. Cela permet d'aligner les règles contractuelles sur l'offre respective, au lieu de les transférer globalement à chaque modèle SaaS.

Il faut distinguer l'EU Data Act et le RGPD : selon MME, le Data Act s'applique parallèlement au RGPD et couvre également les données machine ou produit non personnelles. Lors de la migration de données produit, des exigences supplémentaires du RGPD peuvent s'appliquer si des données personnelles sont concernées (MME). Recensez donc la catégorie de données et le possible lien avec l'UE séparément des obligations de conservation suisses.

Pour les contrats avec un lien suisse, le choix du droit doit être vérifié. L'expertise Cloud pour la ville de Zurich mentionne la règle « Le droit suisse convenu dans le contrat s'applique. » Celui qui convient du droit suisse règle la restitution et la suppression selon ce droit et non uniquement selon les CGV du fournisseur.

Droit suisse vs EU Data Act : Différences lors de la restitution et de la suppression des données