Data Act et sous-traitants cloud : responsabilités

Un fournisseur cloud soumis au Data Act doit rendre le changement de service possible : décrire les éléments exportables, organiser l’assistance, maintenir la continuité et prévoir une récupération avant effacement. Il ne peut renvoyer toute la migration au client. Inversement, le texte ne l’oblige pas à reconstruire gratuitement chaque fonction chez un concurrent.

Pour le DPO ou le responsable informatique, la première décision consiste à séparer trois engagements : ce que fournit le prestataire sortant, ce que reprend le prestataire entrant et ce que l’entreprise doit valider. Cette répartition complète le contrat de sous-traitance RGPD ; elle ne le remplace pas.

Qualifier le service, pas seulement le prestataire

Le chapitre VI concerne les services répondant à la définition de l’Art. 2(8) : accès par réseau, à la demande, à des ressources informatiques partagées, configurables et rapidement mobilisables. Des offres d’infrastructure, de plateforme ou de logiciel en ligne peuvent entrer dans ce périmètre. Une licence installée localement ne devient pas un service concerné par la seule présence du mot « cloud » dans la brochure. Le fournisseur peut être établi hors de l’Union s’il fournit ces services à des clients dans l’Union. Data Act, Art. 1(3)(f) et 2(8).

La qualification RGPD répond à une autre question : traite-t-il des données personnelles pour votre compte ? Un même service peut relever des deux régimes. Son obligation de sortie peut aussi porter sur des données non personnelles : catalogues, paramètres ou documents techniques. Limiter le dossier aux coordonnées des personnes ferait donc manquer une partie du besoin.

La qualification doit être écrite pour chaque offre concernée. Identifiez le contrat, le service effectivement fourni et les éventuelles exceptions invoquées. Une réponse générale « nous sommes seulement éditeur » n’explique pas pourquoi la définition légale serait écartée.

Ce que le fournisseur sortant doit réellement prendre en charge

L’Art. 25(2)(a) prévoit une assistance raisonnable au client et aux tiers qu’il autorise. Pendant la transition, le fournisseur poursuit ses engagements de service, agit avec diligence pour préserver la continuité, signale les risques connus qui relèvent de lui et maintient un niveau élevé de sécurité, y compris pendant la récupération.

L’Art. 26 ajoute une obligation documentaire : procédures, méthodes, formats, limites techniques connues et référence à un registre en ligne actualisé des structures et formats. Le client doit ainsi pouvoir comprendre ce qu’il recevra, sans découvrir au dernier moment qu’un export ne contient pas les pièces jointes.

La limite figure à l’Art. 24 : les responsabilités techniques concernées portent sur les services, contrats et pratiques du fournisseur d’origine. L’Art. 27 oblige néanmoins toutes les parties, destination comprise, à coopérer de bonne foi. Data Act, Art. 24 à 27.

Conséquence pratique : le prestataire sortant documente la signification de son champ « statut ». Le prestataire entrant organise sa correspondance avec les états de son application. Le client tranche la règle métier, par exemple si un ancien dossier « suspendu » doit rester non facturable. Aucun acteur ne peut raisonnablement prendre seul ces trois décisions.

Une annexe de responsabilités directement exploitable

Prenons un exemple hypothétique : une PME quitte un logiciel de gestion d’interventions pour un autre. L’offre entre dans le chapitre VI et aucune exception de l’Art. 31 n’est retenue. Le périmètre choisi comprend les interventions, leurs comptes rendus et les relations entre dossiers. Il ne s’agit pas d’un essai réalisé sur un produit.

L’annexe suivante illustre une répartition à adapter au service. Les livrables constituent des propositions contractuelles concrètes, pas une liste réglementaire universelle.

La ligne sur les pièces jointes est déterminante. Recevoir un dossier contenant tous les fichiers ne suffit pas si personne ne sait à quelle intervention ils correspondent. Une empreinte numérique peut aider à contrôler l’intégrité d’un fichier ; elle ne démontre ni ce rattachement ni l’exhaustivité des catégories exportées.

Pour cette PME, la réception doit donc porter sur les relations et les droits d’accès, en plus du nombre de lignes. Si les pièces sont présentes mais leurs identifiants absents, elle demande au fournisseur sortant la correspondance manquante. Si cette correspondance existe mais que l’importeur ne l’utilise pas, l’action revient au prestataire entrant. La difficulté cesse d’être un renvoi indifférencié entre supports.

Commenter une clause de sortie avant de la signer

Voici une formulation illustrative pour le même projet, à intégrer dans une annexe plus complète :

Le fournisseur sortant remet les catégories décrites dans l’annexe d’export, avec leur documentation et les relations nécessaires à leur exploitation. Le client désigne les personnes autorisées à les recevoir. Le prestataire entrant décrit les transformations réalisées et les écarts constatés. La réception est documentée par catégorie ; une réserve identifiée précise son responsable et son traitement avant la clôture du changement.

« Catégories décrites » suppose une annexe réelle. L’Art. 25(2)(e) exige une spécification exhaustive des catégories transférables, incluant au minimum toutes les données exportables. La définition de l’Art. 2(38) comprend les entrées, sorties et métadonnées générées par l’utilisation du service, sous les exclusions qu’elle prévoit.

« Personnes autorisées » évite d’envoyer l’intégralité des données à une adresse simplement mentionnée dans un ticket. Le client valide le mandat, le canal de réception et les droits du destinataire. Le transfert doit rester sécurisé ; une urgence de calendrier ne rend pas acceptable un lien public.

« Réception par catégorie » ne permet pas au fournisseur d’effacer les autres catégories dès qu’un premier fichier est téléchargé. Elle sert à identifier les réserves. Les échéances légales de récupération et la réussite du changement restent à respecter. La clause ne remplace donc ni le calendrier complet de l’Art. 25 ni les instructions d’effacement.

Distinguer export, interopérabilité et reconstruction

Pour les services d’infrastructure précisément visés à l’Art. 30(1), le fournisseur doit prendre les mesures raisonnables en son pouvoir afin de faciliter l’équivalence fonctionnelle entre services du même type. Cela vise un résultat minimal comparable pour les fonctionnalités partagées, pas une identité de toutes les architectures.

Pour les autres services concernés, l’Art. 30(2) impose des interfaces ouvertes gratuites facilitant le changement. L’Art. 30(5) prévoit, en cas de changement vers un service du même type et en l’absence des spécifications ou normes visées, l’export sur demande dans un format structuré, couramment utilisé et lisible par machine. L’Art. 30(6) ne contraint pas à développer une technologie nouvelle ou à céder des actifs protégés. Data Act, Art. 2(37) et 30.

Dans notre exemple, reprendre les interventions ne signifie pas recevoir le code source propriétaire de l’application. En revanche, invoquer ce code pour refuser indistinctement tous les statuts ou toutes les métadonnées ne résout pas l’obligation d’export. Une exclusion doit être précisément qualifiée. Le guide sur l’interopérabilité des données explique comment séparer format, signification et comportement attendu.

Prévoir une récupération avant l’effacement

Le contrat doit prévoir un préavis de lancement n’excédant pas deux mois, puis une transition en principe limitée à trente jours calendaires. Une impossibilité technique doit être motivée dans les quatorze jours ouvrables suivant la demande ; l’autre période indiquée ne peut dépasser sept mois. Le client dispose aussi du droit contractuel de prolonger une fois la transition pour une durée plus appropriée à ses besoins. Data Act, Art. 25(2), (4) et (5).

Après la transition vient une période de récupération d’au moins trente jours calendaires. L’effacement de l’Art. 25(2)(h) intervient après cette période, ou une période ultérieure convenue, sous condition de réussite du changement. « Export livré » et « changement réussi » ne sont donc pas des événements interchangeables.

Lorsque des données personnelles sont traitées, coordonnez ce calendrier avec le choix de restitution ou suppression prévu par l’Art. 28(3)(g) du RGPD, y compris les copies et l’exception de conservation légalement imposée. Une sauvegarde ne constitue pas une dispense générale d’effacement. Les instructions doivent couvrir son échéance, son accès restreint et le traitement d’une éventuelle restauration. RGPD, Art. 28(3)(g) et 32.

Le contrat de sous-traitance RGPD fixe ces instructions ; le guide de portabilité cloud approfondit l’enchaînement des opérations. Conservez une preuve de clôture distinguant récupération, suppression et révocation des accès.

Examiner les frais ligne par ligne

En France, l’arrêté du 17 novembre 2025, Art. 1 et 2, fixe à zéro les frais de transfert de données entrant dans son champ, du 1er décembre 2025 au 12 janvier 2027. À cette dernière date, l’Art. 29(1) interdit les frais de changement relevant du régime européen.

Cela n’efface pas indistinctement abonnements, éventuelles pénalités de résiliation anticipée et prestations supplémentaires. Les lignes directrices Arcep du 2 juillet 2026, section 2.2 distinguent l’assistance obligatoire d’un accompagnement additionnel demandé et accepté. Le simple fait que le client ait demandé une action ne la rend pas supplémentaire.

Demandez donc un devis ventilé : transfert, assistance relevant des obligations, transformation supplémentaire et services maintenus. Contestez la qualification d’une ligne avant d’accepter son prix ; une appellation « conseil » ne tranche pas sa nature. Ne déduisez pas davantage d’un désaccord le droit de suspendre tous les paiements.

Ce qu’il faut retenir

Le fournisseur sortant doit rendre les données et la sortie exploitables. Le client reste responsable des décisions métier et de la réception ; le prestataire entrant participe à la reprise. Une annexe précise relie chaque opération à un responsable, un livrable et une réserve éventuelle. L’effacement attend les conditions prévues, tandis que les frais doivent être qualifiés séparément.

FAQ

Un service sur mesure échappe-t-il à toutes ces obligations ?

Non. L’Art. 31(1) écarte seulement certaines obligations, dont celles de l’Art. 29. Ses critères portent sur la conception spécifique et l’absence de commercialisation à grande échelle par catalogue. Un paramétrage ordinaire ne suffit pas à les établir.

Une version d’essai est-elle toujours exclue ?

L’Art. 31(2) vise une version non destinée à la production, fournie pour essai et évaluation pendant une durée limitée. Une offre gratuite effectivement utilisée en production ne peut être exclue sur ce seul motif.

Que faire si le fournisseur ne décrit pas son export ?

Adressez une demande écrite fondée sur les Art. 25(2)(e) et 26, en nommant les catégories nécessaires et les informations absentes. Sans réponse exploitable, documentez le blocage, organisez son escalade contractuelle et ne validez pas une réception dont vous ne pouvez établir le périmètre.

Recevez nos analyses pratiques sur la conformité : inscrivez-vous à la newsletter.

Thiébaut Devergranne est docteur en droit et fondateur de donneespersonnelles.fr. Il travaille depuis plus de vingt ans sur le droit des technologies et la protection des données personnelles.