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

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

Les contrats SaaS définissent 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 système sont tout aussi cruciales. Celui qui ne règle la restitution et la suppression qu'au moment de la résiliation négocie dans une phase où le fournisseur contrôle déjà 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, le EU Data Act s'applique parallèlement au RGPD et couvre également les données non personnelles relatives aux machines ou aux produits. 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 intégrés, comment les systèmes communiquent et quelle partie contrôle les données et les fonctions (Lezzi Legal). Les clauses relatives à l'utilisation, à l'exportation et à la sortie des données doivent donc être adaptées à chaque produit en fonction des flux de données réels, et non reprises sous forme de texte standard.

Les produits SaaS évoluent plus vite que les contrats : les fonctions, les modèles de tarification, 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 entièrement reconstruite à chaque ajustement technique.

Recenser l'existant et les dépendances avant la résiliation

Avant la résiliation, un inventaire doit être établi : données de l'application principale, rapports, résultats OCR, données de contact et d'agenda, 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 est également transféré vers d'autres systèmes. C'est seulement cette distinction qui 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 révèlent des dépendances typiques : la reconnaissance OCR lit directement les pièces justificatives, marque automatiquement en jaune les données saisies et apprend avec chaque nouvelle pièce du même fournisseur. Via CardDAV, les données de contact professionnel sont récupérées pour les entreprises, le personnel et les personnes de contact, 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 métier basés sur le web. Pour le central téléphonique 3CX, une clé API est enregistrée depuis l'espace profil (MOCO).

Ces extensions ont leurs propres grilles tarifaires et leur propre logique de résiliation. Pour l'OCR, le fournisseur indique un coût de 0,25 CHF respectivement 0,20 EUR par pièce justificative lue, en tant que coûts variables refacturés d'un service externe, sans frais de base, avec un budget mensuel ; le service peut être interrompu à 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 qu'il faut prendre en compte lors de la planification de l'exportation et de la fenêtre de sauvegarde.

Outre les flux de données, il faut recenser les clés : 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.

Coûts et délais pour les extensions SaaS lors de la sortie

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 la reconduction 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 concordent pas.

Si la prestation contractuellement convenue relève du EU Data Act, la conception n'est plus libre : les durées de contrat typiques de 12 à 24 mois seront à l'avenir interdites selon MME, et tous les clients disposeront d'un droit de résiliation à tout moment avec un préavis de 60 jours – même dans le cadre de contrats B2B. Les abonnements de longue durée avec un long délai de résiliation ne font dans ce cas plus l'objet du contrat.

La clause doit couvrir trois prestations : la restitution des données, la suppression à l'expiration d'éventuelles obligations de conservation et le soutien à la migration vers un autre fournisseur. Là où le 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 non seulement dans la description du support.

Étapes pour une restitution et une suppression sûres des données lors d'une sortie SaaS

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, par quel canal et jusqu'à quand elles seront restituées. Les API, les webhooks et les exports standard sont envisageables comme canaux. Dans la pratique, la connexion API dépend 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 la fin 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 où les contacts ont été ajoutés, selon la description du fournisseur. Une exportation depuis le SaaS ne capture pas automatiquement ces copies sur les appareils finaux ; il convient donc de clarifier contractuellement qui les supprime après la sortie.

La concrétisation comprend : les responsabilités des deux côtés, les délais de remise, le format de livraison, les indications sur l'exhaustivité (par exemple des jeux de données réconciliés) et une phase de réception pendant laquelle le client peut vérifier l'exportation. Il faut également régler ce qui se passe en cas d'exportation échouée ou incomplète et jusqu'à quand l'accès est maintenu après la remise. Les services peuvent prendre fin à court terme – l'extension OCR peut être interrompue à tout moment sans délai de résiliation – c'est pourquoi l'exportation doit être placée dans une fenêtre temporelle avec un accès garanti.

Convenir d'une suppression traçable et exhaustive

La clause de suppression doit couvrir quatre catégories : les données personnelles, les données de produits et de machines, les sauvegardes ainsi que les copies chez les sous-traitants et autres prestataires engagés. Pour chaque catégorie, il faut déterminer le délai de suppression, les exceptions (p. ex. obligations légales de conservation) et la preuve attestant de la suppression. Lors de la migration de données de produits, des exigences supplémentaires du RGPD peuvent s'appliquer dans la mesure où des données personnelles sont concernées (MME).

La chaîne d'instructions doit être sécurisée contractuellement. Dans les CG de Libra AI, le sous-traitant s'engage à informer immédiatement le client si une instruction lui semble contraire au droit en vigueur sur 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 (point de contact, délai, forme) devrait être définie avant la sortie.

Comme preuves, il faut prévoir une confirmation écrite de suppression avec la 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 fournies et jusqu'à quand elles doivent être disponibles après la fin de la suppression.

Accompagner activement la migration vers le nouveau fournisseur

Là où le EU Data Act est applicable, un soutien obligatoire à la migration s'applique : les entreprises qui relèvent de la loi doivent soutenir activement une migration souhaitée par le client vers un autre fournisseur – selon MME, avec pour conséquence qu'elles aident gratuitement leurs concurrents à gagner de nouveaux clients. Cette obligation est indépendante du fait que le fournisseur juge la migration judicieuse ou non.

Les limites de l'aide doivent être tracées contractuellement : quelles données et quels formats, quelle durée, quels interlocuteurs, quelle collaboration du client. Sans une telle précision, il reste ouvert de savoir 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 d'affaires et de vente.

Avantages et risques du soutien à la migration selon le EU Data Act

Harmoniser le contrat, les CG, le DPA et la documentation sur la protection des données

Pour les modèles standardisés, le contrat SaaS, les CG, 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 dans un document et les règles de conservation ou de suppression dans un autre divergent, des contradictions apparaissent, qui sont interprétées contre le fournisseur en cas de litige.

La hiérarchie détermine quel document s'applique. Les CG de Libra AI prévoient que les conditions générales divergentes du client ne trouvent pas à s'appliquer, à moins que le fournisseur n'accepte expressément leur validité par écrit, et que les CG 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 CG.

Concrètement, cela signifie : regrouper les règles de sortie de manière complète à un seul endroit, y renvoyer depuis tous les autres documents et les faire évoluer avec chaque modification du produit. Étant donné que les fonctions, les modèles de tarification et les intégrations changent continuellement, la documentation doit, selon Lezzi Legal, être conçue de manière à pouvoir évoluer avec le produit.

Précision contractuelle : que faut-il régler avant une sortie SaaS ?

Situer le contexte suisse et les liens avec l'UE

Pour les entreprises suisses de SaaS et d'IoT actives sur le marché de l'UE, le EU Data Act (règlement (UE) 2023/2854 concernant des règles harmonisées sur un accès équitable aux données et un usage équitable des données) a créé, depuis son entrée en vigueur mi-septembre 2025, un nouvel environnement réglementaire (MME).

Avant l'adaptation des contrats, il convient de vérifier l'applicabilité : tous les modèles SaaS ne relèvent pas de la réglementation, même si des affirmations partiellement contradictoires circulent à ce sujet (MME). Les petites et moyennes entreprises ne sont pas fondamentalement exclues, mais exemptées de certaines obligations – ainsi, les entreprises IoT réalisant un chiffre d'affaires inférieur à 10 millions EUR n'ont pas à fournir de soutien à la migration (MME). Celui qui saute cette vérification adapte peut-être ses contrats sans raison ou néglige des obligations qui s'appliquent effectivement.

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 spécifiques aux secteurs, et pour les entreprises ayant un lien avec l'UE, l'EU AI Act peut également être pertinent (Lezzi Legal). L'évolution 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 simple de migrer sa propre infrastructure cloud vers un autre fournisseur.

Application du EU Data Act aux entreprises suisses de SaaS