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, à leur exportation et à la sortie du service sont tout aussi importantes. Celui qui ne clarifie la restitution et la suppression qu'au moment de la résiliation se retrouve à négocier 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 machines ou produits 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 prestataires sont impliqués, comment les systèmes communiquent et quelle partie contrôle les données et les fonctionnalités (Lezzi Legal). Les clauses relatives à l'utilisation des données, à l'exportation et à la sortie doivent donc être adaptées aux flux de données réels pour chaque produit, 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.

Les bases juridiques déterminantes pour la sortie sont l'EU Data Act (règlement (UE) 2023/2854) et, dans la mesure où des données personnelles sont concernées, le RGPD. Pour les entreprises ayant des liens avec l'UE, l'EU AI Act peut également être pertinent (Lezzi Legal).

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 permet de déterminer quelles données peuvent être couvertes par une exportation depuis le SaaS et lesquelles doivent être sauvegardées séparément.

Les extensions d'un logiciel ERP et d'agence illustrent des dépendances typiques : la reconnaissance OCR lit directement les pièces justificatives, marque automatiquement en jaune les données préremplies et apprend avec chaque nouvelle pièce du même fournisseur. Via CardDAV, les données professionnelles 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 commerciaux 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).

Ces extensions ont leurs propres tarifs et leur propre logique de cessation. Selon le fournisseur, l'OCR entraîne des coûts de 0,25 CHF ou 0,20 EUR par pièce lue, facturés comme des coûts variables liés à la consommation d'un service externe, sans frais de base, avec un budget mensuel ; le service peut être arrêté à tout moment sans délai de résiliation (MOCO). Un flux de données peut ainsi prendre fin indépendamment du contrat principal et à court terme – ce qui doit être pris en compte lors de la planification de l'exportation et de la fenêtre de sauvegarde.

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 distincts qui doivent être transférés lors de la restitution ou supprimés ensuite.

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'exportation 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, sa conception n'est plus libre. Selon MME, les durées contractuelles typiques de 12 à 24 mois seront interdites à l'avenir. Tous les clients disposent d'un droit de résiliation de 60 jours valable en tout temps – y compris pour les contrats B2B. Les abonnements de longue durée avec un long délai de résiliation ne font plus partie de l'objet du contrat dans ce cas.

La clause doit refléter 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. Lorsque l'EU Data Act est applicable, la migration souhaitée par le client doit être activement soutenue (MME) – cette obligation doit figurer explicitement dans le contrat et pas seulement dans la description du support.

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 informations sont disponibles.

Les obligations post-contractuelles doivent figurer expressément 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 formulées de manière à survivre à la fin du contrat.

Concrétiser la restitution des données en termes de formats, canaux et délais

Pour chaque type de données, il faut définir sous quelle forme, via quel canal et jusqu'à quand elles sont restituées. Les API, les WebHooks et les exports standards sont des canaux possibles. La connexion API dépend en 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égler quelles clés restent valables pendant la fenêtre d'exportation, 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. Selon la description du fournisseur, les données récupérées via CardDAV sont affichées de manière synchronisée sur les appareils sur lesquels les contacts ont été ajoutés. Une exportation 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égler 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é.

La granularité fait également partie des spécifications de format : la sortie OCR peut être lue globalement comme un seul poste ou comme des postes individuels (MOCO). La clause devrait indiquer quel niveau de détail le client nécessite pour la ré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). Ces accès ne doivent être révoqués que lorsque l'export est terminé et accepté.

Convenir d'une suppression traçable et complète

La clause de suppression doit couvrir quatre catégories : les données personnelles, les données produits et machines, 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 produits, 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 actuel de la 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 la demande de suppression et une information sur le cercle des sous-traitants. Il faut également régler sous quelle forme ces confirmations sont délivrées et jusqu'à quand elles doivent être disponibles après l'achèvement de la suppression.

Bases juridiques : le RGPD s'applique aux données personnelles, tandis que l'EU Data Act, qui est applicable parallèlement, s'applique aux données machines ou produits non personnelles (MME). La clause de suppression devrait mentionner expressément ces deux cadres réglementaires.

Accompagner activement la migration vers le nouveau fournisseur

Lorsque l'EU Data Act est applicable, un soutien obligatoire à la migration s'impose. Les entreprises soumises à cette loi doivent soutenir activement une migration vers un autre fournisseur souhaitée par le client. Selon MME, cela a pour conséquence qu'elles aident gratuitement leurs concurrents à acquérir de nouveaux clients. Cette obligation existe indépendamment du fait que le fournisseur juge la migration judicieuse ou non.

Les limites de cette assistance doivent être tracées contractuellement : quelles données et formats, quelle période, quels interlocuteurs, quelle collaboration de la part du client. Sans une telle précision, il reste ouvert ce que « soutenir activement » comprend concrètement.

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 prévues par le droit européen de la protection des données. Déjà aujourd'hui, certains clients SaaS adaptent leurs contrats et, dans certains cas, également 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 doivent ê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 commerciales divergentes du client ne s'appliquent pas. Il en va autrement uniquement si le fournisseur accepte expressément leur validité sous forme textuelle. 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.

Situer le contexte suisse et les implications avec l'UE

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 de SaaS et d'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 de SaaS et d'IoT doivent faire maintenant », 12 janvier 2026).

Avant l'adaptation du contrat vient l'examen de l'applicabilité : tous les modèles SaaS ne relèvent pas de cette réglementation, même si des affirmations partiellement contradictoires circulent à ce sujet (MME). Les petites et moyennes entreprises ne sont pas fondamentalement exclues, mais sont exemptées de certaines obligations – ainsi, les entreprises IoT dont le chiffre d'affaires est inférieur à 10 millions d'EUR ne sont pas tenues de fournir un soutien à la migration (MME). Celui qui saute cet examen adapte possiblement ses contrats sans raison ou ignore des obligations qui s'appliquent réellement.

Pour la Suisse, il s'ajoute qu'il n'existe jusqu'à présent aucune législation spécifique globale sur l'IA ; les applications d'IA sont couvertes par les domaines juridiques existants et les prescriptions sectorielles, et l'EU AI Act peut également être pertinent pour les entreprises ayant des liens avec l'UE (Lezzi Legal). Le développement réglementaire est en cours. Outre les risques, la loi sur les données offre aussi des opportunités : selon MME, il est devenu plus facile de migrer sa propre infrastructure cloud vers un autre fournisseur.

Pour les contrats ayant un lien avec la Suisse, le choix du droit doit être examiné. 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 pas uniquement selon les CGV du fournisseur.

Chiffres clés sur l'applicabilité de l'EU Data Act pour les entreprises suisses de SaaS