Data Act pour freelances : données client, contrats SaaS et réversibilité (guide 2026)

Depuis le 12 septembre 2025, la plupart des dispositions du Data Act s’appliquent en Europe, selon la CNIL. Pour un freelance qui touche au SaaS, à la data, au cloud, au no-code, à l’IoT ou à l’IA, ce n’est pas un détail de juriste. C’est une question de contrat, d’export et de réversibilité.

Tu ouvres l’outil SaaS de ton client pour préparer une migration. Le brief paraît simple : exporter les données, nettoyer les champs, reconstruire les tableaux de bord dans un nouvel outil, puis couper l’ancien abonnement.

Sauf qu’au moment de télécharger les données, rien n’est clair. L’export est incomplet. Les pièces jointes restent bloquées. L’API impose des limites. Le contrat parle de frais de migration, mais personne ne sait ce qu’ils couvrent. Et le client te demande : “On a le droit de récupérer quoi, exactement ?”

J’ai déjà vu ce scénario sur des migrations qui semblaient purement techniques au départ. Le blocage ne venait pas du script d’export, mais du contrat, des droits d’accès ou d’une dépendance que personne n’avait documentée.

C’est là que le Data Act freelance devient utile. Pas comme un texte abstrait à réciter, mais comme une grille de lecture pour tes missions SaaS, data, cloud, IoT, no-code ou IA. On va voir ce que le règlement change, ce qu’il ne change pas, et comment l’utiliser pour sécuriser tes contrats.

Ce guide ne remplace pas un avocat. Il te donne une méthode opérationnelle pour poser les bonnes questions avant de toucher aux données d’un client.

Dès qu’une mission dépend d’un export, d’une API, d’un outil cloud ou d’une base client, la réversibilité n’est plus un détail technique. C’est un point contractuel.

Ce que le Data Act change pour une mission freelance

Le Data Act est le nom courant du règlement UE 2023/2854, aussi appelé règlement européen sur les données. La Commission européenne le présente comme un cadre destiné à rendre les données plus accessibles, plus utilisables et mieux réparties entre les acteurs économiques.

Dit plus simplement : le texte donne davantage de contrôle aux utilisateurs sur les données générées par des produits connectés et encadre aussi les contrats qui empêchent de changer de fournisseur de services de traitement de données, notamment cloud, edge, PaaS et certains SaaS.

Pour un freelance, le sujet apparaît surtout dans quatre situations.

• Tu aides un client à récupérer ses données depuis un outil SaaS.
• Tu construis un dashboard, une API, un pipeline data ou une automatisation.
• Tu accompagnes une migration cloud, CRM, ERP, BI ou no-code.
• Tu livres un outil IA alimenté par des données métier du client.

Le Data Act ne transforme pas chaque freelance en juriste. En revanche, il rend plus difficile l’ancienne approche : “On verra l’export à la fin.”

On ne peut plus traiter les données comme un sous-produit flou de la mission. Il faut savoir qui les détient, qui peut les utiliser, dans quel format elles sortent, combien coûte la migration et ce qui reste chez le prestataire après la fin du contrat.

Ce que le Data Act n’est pas

Le Data Act ne remplace pas le RGPD. La CNIL rappelle que le RGPD continue de s’appliquer dès qu’une donnée personnelle est concernée : base légale, information, sécurité, droits des personnes, rôle de responsable de traitement ou de sous-traitant.

Il ne remplace pas non plus l’AI Act. Si tu livres un chatbot, un scoring, un assistant métier ou un workflow IA, il faut regarder le cadre IA en plus du cadre data. On a détaillé cette logique dans le guide AI Act pour freelances.

Le Data Act ne règle pas toute la propriété intellectuelle. Une base de données, un code source, une documentation technique, un modèle de données ou un secret d’affaires peuvent être protégés par d’autres règles. Si ton livrable mélange données client, scripts, templates et méthodes personnelles, relis aussi le guide sur la propriété intellectuelle en freelance.

Enfin, le Data Act n’est pas le Cloud Act américain. Le Cloud Act concerne certaines demandes d’accès par les autorités américaines auprès de fournisseurs soumis au droit américain. Le Data Act européen contient, lui, des garanties sur l’accès de gouvernements de pays tiers aux données non personnelles détenues dans l’Union européenne.

Le bon réflexe : ne pas choisir entre RGPD, Data Act, AI Act et propriété intellectuelle. On identifie la nature des données, puis on applique les cadres qui correspondent.

Le calendrier 2025-2027 à garder sous les yeux

Le règlement est entré en vigueur le 11 janvier 2024, puis il s’applique principalement depuis le 12 septembre 2025. Pour une mission signée en 2026, on est donc déjà dans la phase opérationnelle.

La CNIL résume plusieurs jalons importants pour les entreprises et les prestataires.

Date	Ce qui change	Impact pour un freelance
12 septembre 2025	Application principale de la plupart des dispositions du Data Act	Les nouveaux contrats SaaS, cloud, data ou IoT doivent être relus avec une logique d’accès, de partage et de réversibilité.
12 septembre 2026	Les objets connectés et services associés mis sur le marché doivent être conçus pour rendre les données directement accessibles quand c’est techniquement possible	Les missions IoT, industrie, mobilité, capteurs, smart building ou produits connectés doivent intégrer l’accès aux données dès la conception.
12 janvier 2027	Les bénéficiaires de services cloud doivent pouvoir changer de fournisseur sans frais de changement	Les audits cloud et FinOps doivent distinguer frais de prestation additionnelle et frais interdits liés au changement.
12 septembre 2027	L’interdiction des clauses abusives s’applique aussi à certains contrats conclus le 12 septembre 2025 ou avant cette date, s’ils sont à durée indéterminée ou arrivent à échéance au moins dix ans après le 11 janvier 2024	Les anciens contrats SaaS ou data imposés par un acteur plus puissant pourront être réexaminés sous cet angle, surtout lorsqu’ils engagent le client longtemps.

La Commission européenne précise aussi que les fournisseurs de services de traitement de données, notamment cloud, edge, PaaS et SaaS, doivent réduire les obstacles au changement de fournisseur. À partir du 12 janvier 2027, les frais de changement et de sortie des données doivent disparaître pour les opérations nécessaires au changement.

Attention à la nuance : cela ne veut pas dire que toute mission de migration devient gratuite. Un freelance peut toujours facturer son travail d’audit, de nettoyage, de mapping, de documentation ou de reprise de données. Ce qui est visé, ce sont les frais imposés par le fournisseur source pour empêcher ou alourdir le changement.

Quels freelances sont concernés ?

On pense souvent que le Data Act concerne seulement les grandes plateformes. C’est trop court. Beaucoup de freelances interviennent au milieu de la chaîne, là où les données circulent, se transforment et changent d’outil.

Tu es concerné si tu travailles dans l’une de ces activités.

• Développement SaaS ou maintenance applicative.
• Intégration no-code avec Notion, Airtable, Make, Zapier, n8n, Softr ou Bubble. Si tu vends déjà des automatisations, le guide automatiser son activité freelance avec le no-code complète bien cette logique.
• Data analysis, BI, dashboarding, data engineering.
• Cloud engineering, DevOps, FinOps, infogérance.
• Conseil IA, RAG, automatisation, agents connectés à une base client.
• IoT, objets connectés, capteurs, applications industrielles.
• CRM, marketing automation, support client, ERP.
• Agence ou micro-agence qui livre des outils métier.

Le niveau de responsabilité dépend de ton rôle. Un consultant qui audite un contrat SaaS n’a pas la même exposition qu’un éditeur qui héberge les données de plusieurs clients. Un intégrateur qui connecte deux API n’a pas le même poids qu’un fournisseur de plateforme cloud.

Mais dans tous les cas, tu dois savoir expliquer ton périmètre.

Plus tu es proche du système qui stocke, transforme ou bloque les données, plus tu dois cadrer la réversibilité dans ton contrat.

Quels droits ton client peut faire valoir sur ses données ?

Le Data Act donne aux utilisateurs de produits connectés et de services associés un meilleur accès aux données générées par leur utilisation. Il couvre les données personnelles et non personnelles, avec une articulation constante avec le RGPD.

Dans les missions freelance, on peut traduire ces droits en cinq réflexes.

Accéder aux données

Le client doit pouvoir comprendre quelles données sont générées, où elles se trouvent et comment elles sont accessibles. Dans un outil métier, cela peut viser les données saisies par les équipes, les logs d’usage, les métadonnées, les historiques, les fichiers joints, les exports et certains résultats produits par le service.

Si tu construis un outil interne, documente dès le départ les tables, les champs, les formats et les dépendances. Même une documentation simple peut éviter une mission de sauvetage six mois plus tard.

Partager les données avec un tiers

Le Data Act permet à l’utilisateur de demander que certaines données soient partagées avec un destinataire de son choix. Dans une mission, le tiers peut être toi, un autre prestataire, un nouvel éditeur SaaS, une agence data ou une équipe interne.

Exemple : un client utilise un outil de gestion de flotte connecté. Il veut transmettre les données d’usage à un consultant BI pour créer un tableau de bord de maintenance. Le point à cadrer n’est pas seulement technique. Il faut vérifier le droit d’accès, les secrets d’affaires, la sécurité, le format et les limites d’utilisation.

Obtenir des formats exploitables

Un export CSV illisible, sans dictionnaire de données, sans identifiant stable et sans historique utile ne sert pas à grand-chose. La Commission européenne insiste sur les formats couramment utilisés et lisibles par machine pour les services SaaS et PaaS.

Pour un freelance, c’est un levier très concret : demander un export exploitable, ce n’est pas être pénible. C’est protéger la continuité du projet.

Distinguer données brutes, données prétraitées et résultats dérivés

Le Data Act vise surtout les données générées par l’utilisation d’un produit connecté ou d’un service associé, ainsi que les métadonnées nécessaires pour les comprendre. Le règlement parle notamment de données brutes, de données sources, de données primaires et de données prétraitées pour les rendre utilisables.

En revanche, tout ce qui résulte d’un investissement supplémentaire peut sortir du périmètre automatique : scoring propriétaire, segment marketing, modèle prédictif, enrichissement métier, algorithme de recommandation ou indicateur calculé avec une méthode interne. Ces éléments peuvent relever de la propriété intellectuelle, du secret d’affaires ou d’un accord contractuel spécifique.

Dans une mission, cette nuance change beaucoup de choses. Ton client peut demander les données nécessaires à la reprise d’un outil, mais il ne récupère pas forcément toute la logique propriétaire de l’éditeur ou tous les modèles créés par un tiers. On doit donc nommer précisément ce qui est exporté : tables, fichiers, logs, métadonnées, historiques, scores, formules, modèles, documentation.

Un bon export ne se limite pas au fichier. Il inclut aussi le contexte qui permet de réutiliser les données sans deviner.

Réutiliser les données

Le client peut vouloir réutiliser ses données pour améliorer un process, entraîner un outil interne, créer un reporting ou changer d’éditeur. Mais cette réutilisation n’est pas illimitée. Il faut tenir compte des données personnelles, des secrets d’affaires, des licences, des droits de propriété intellectuelle et des clauses de confidentialité.

Dans un projet IA, par exemple, on évite d’utiliser les données d’un client pour améliorer une solution réutilisée chez d’autres clients sans autorisation écrite. C’est une zone à risque.

Changer de fournisseur

Le Data Act traite aussi la possibilité de passer d’un service de traitement de données à un autre. Cela vise notamment les services cloud, mais aussi certains services numériques qui stockent, traitent ou mettent à disposition des données.

Pour un freelance FinOps, cloud ou DevOps, c’est un sujet commercial majeur. On ne vend plus seulement de l’optimisation de coûts. On vend aussi de la liberté de mouvement : sortir d’un fournisseur, réduire la dépendance, documenter les dépendances techniques et préparer un plan de réversibilité.

Si tu veux te positionner sur ce terrain, le guide devenir consultant FinOps freelance donne une bonne base sur les missions et les compétences attendues.

Quel rôle joues-tu dans la chaîne ?

Avant de promettre quoi que ce soit, on clarifie ton rôle. C’est souvent là que les contrats deviennent dangereux : le client pense acheter une conformité globale, alors que tu vends une prestation technique limitée.

Ton rôle	Exemple de mission	Point de vigilance
Simple prestataire	Exporter une base, nettoyer des fichiers, créer un dashboard	Ne pas promettre plus que le périmètre livré.
Sous-traitant RGPD	Migrer un CRM contenant prospects, clients et tickets support	Signer ou vérifier le DPA, puis protéger les données personnelles.
Éditeur SaaS freelance	Vendre un outil métier hébergé pour plusieurs clients	Prévoir exports, suppression, assistance et sortie du service.
Intégrateur ou mainteneur	Connecter Notion, Airtable, HubSpot, Make, Power BI ou une API	Documenter les flux, les accès et les dépendances.
Fournisseur cloud indirect	Héberger une application client sur ton compte ou ton infra	Cadrer la réversibilité, les sauvegardes, les délais et les coûts.

Simple prestataire

Tu interviens sur une tâche précise : exporter des données, créer un dashboard, documenter une API, migrer un CRM ou nettoyer une base.

Ton obligation principale est de respecter le contrat, la confidentialité et les consignes du client. Si tu manipules des données personnelles pour son compte, tu peux aussi être sous-traitant RGPD.

Ce qu’il faut écrire : ton périmètre, les accès nécessaires, les livrables, les exclusions, les limites de responsabilité et la suppression des copies de travail en fin de mission.

Sous-traitant RGPD

Tu es sous-traitant RGPD si tu traites des données personnelles pour le compte du client et selon ses instructions. Exemple : migration d’un CRM contenant prospects, clients, emails, historiques d’achat et tickets support.

Dans ce cas, le DPA doit cadrer les finalités, les catégories de données, la durée, les mesures de sécurité, les sous-traitants ultérieurs et la suppression ou restitution des données. Le Data Act peut s’ajouter, mais il ne retire aucune obligation RGPD.

Éditeur SaaS freelance

Si tu exploites ton propre SaaS, même petit, tu peux être directement concerné par les obligations de changement, d’export, de transparence et de réversibilité. C’est encore plus sensible si ton outil stocke des données métier critiques.

À vérifier : formats d’export, API, préavis, suppression, sauvegardes, dépendances cloud, documentation et assistance à la migration.

Intégrateur ou mainteneur

Tu n’es pas propriétaire des outils, mais tu sais comment les données circulent. Ton rôle consiste souvent à connecter Notion, Airtable, HubSpot, Stripe, Google Sheets, Power BI, Make, Zapier ou une base SQL.

Le risque : devenir le seul à comprendre l’architecture. Si tu pars, le client ne sait plus exporter, migrer ou vérifier ce qui transite.

Un bon livrable doit donc inclure une cartographie des flux, une liste des accès, une documentation des exports et les points de réversibilité.

Fournisseur cloud indirect

Tu peux aussi vendre une prestation hébergée sur ton propre compte cloud ou sur une infrastructure que tu contrôles. Dans ce cas, tu n’es plus seulement consultant. Tu fournis un service continu.

Si le client ne peut pas récupérer ses données sans toi, il faut être très clair sur les conditions de sortie, les formats, le délai, l’assistance, les sauvegardes et la suppression.

Ton contrat doit dire ce que tu fais, mais aussi ce qui se passe quand la mission s’arrête.

Contrats SaaS et cloud : les clauses à relire avant de migrer

Le Data Act rend la réversibilité plus importante dans les contrats SaaS et cloud. On parle ici de la capacité à quitter un outil, récupérer ses données, préserver la continuité et redémarrer ailleurs sans perdre l’essentiel.

Si tu signes une mission qui touche à des données client, relis au moins ces clauses.

Propriété et accès aux données

La clause doit distinguer les données du client, les données générées par l’usage, les livrables, les scripts, les modèles, les logs, les métadonnées et les éléments protégés par le prestataire.

Une phrase vague du type “les données restent la propriété du client” ne suffit pas toujours. Elle ne dit pas comment sortir les données, sous quel format, avec quels délais, ni ce qui est exclu.

Réutilisation des données

Peux-tu utiliser les données client pour tester un script ? Pour entraîner un modèle ? Pour créer une démo ? Pour enrichir une méthode interne ? Pour diagnostiquer un bug après la mission ?

Si ce n’est pas écrit, on évite. Surtout avec des données personnelles, confidentielles ou stratégiques.

Confidentialité et sécurité

La confidentialité doit couvrir les données, les accès, les exports, les secrets d’affaires, les clés API, les identifiants, les documents transmis et les environnements de test.

Ajoute aussi des règles pratiques : pas de stockage local inutile, chiffrement si nécessaire, partage via coffre-fort, suppression des fichiers temporaires, limitation des accès.

Sous-traitants et outils tiers

Dans une mission no-code ou IA, les données passent souvent par plusieurs services : Make, Zapier, OpenAI, Google Cloud, AWS, Azure, Supabase, Airtable, Notion, HubSpot, Power BI.

Le client doit savoir quels outils reçoivent quelles données. Si ces données sont personnelles, on revient au DPA et aux transferts éventuels hors Union européenne. Le guide travailler avec des clients étrangers en freelance peut aider à cadrer les flux internationaux.

Réversibilité et assistance à la migration

La clause de réversibilité doit répondre à des questions simples.

• Quels exports sont disponibles ?
• Quels formats sont fournis ?
• Les pièces jointes, logs, métadonnées et historiques sont-ils inclus ?
• Combien de temps le client peut-il récupérer les données après résiliation ?
• Quelle assistance est incluse ?
• Quelle assistance est facturée séparément ?
• Que se passe-t-il si l’ancien outil limite l’API ?

Si tu rédiges ou adaptes ton propre contrat, le guide contrat de mission freelance détaille les clauses indispensables. Pour tes conditions générales, tu peux aussi t’appuyer sur le guide CGV freelance.

Si la mission s’accompagne d’une refonte administrative ou d’un changement d’outil de gestion, pense aussi au sujet voisin de la facturation électronique 2026. Les données de facturation, les identifiants clients et les archives comptables doivent rester récupérables.

Frais de sortie, egress fees et prestations facturables

Le Data Act encadre progressivement les frais liés au changement de fournisseur de services de traitement de données. Jusqu’au 12 janvier 2027, certains frais de changement peuvent encore exister, mais ils doivent rester liés aux coûts directement supportés par le fournisseur. À partir du 12 janvier 2027, les bénéficiaires de services cloud doivent pouvoir changer de fournisseur sans frais de changement.

En pratique, sépare trois lignes dans ton devis ou ton audit.

• Les frais imposés par le fournisseur source pour extraire ou transférer les données.
• Les coûts techniques inévitables : stockage temporaire, trafic réseau, environnement de test, sauvegardes.
• Ta prestation : cadrage, scripts, nettoyage, mapping, tests, recette, documentation et accompagnement.

Cette distinction évite une confusion fréquente. Le Data Act ne t’interdit pas de facturer ton travail de migration. Il oblige surtout à regarder si le fournisseur source utilise ses tarifs, ses délais ou ses limitations techniques pour rendre la sortie artificiellement difficile.

Clauses abusives B2B : les signaux d’alerte

Le Data Act s’attaque aussi aux clauses imposées unilatéralement entre entreprises lorsqu’elles concernent l’accès aux données, l’utilisation des données, la responsabilité ou les recours liés aux données. L’idée n’est pas d’annuler chaque clause défavorable. Un contrat B2B reste négocié. Mais une clause “à prendre ou à laisser” peut devenir problématique si elle crée un déséquilibre fort.

Dans un contrat SaaS, data ou cloud, méfie-toi surtout des formulations qui :

• donnent au fournisseur le droit exclusif de décider si les données livrées sont conformes ;
• empêchent le client d’obtenir une copie des données fournies ou générées pendant le contrat ;
• autorisent une réutilisation large des données client sans finalité claire ;
• limitent fortement les recours du client en cas de manquement sur les données ;
• permettent une modification unilatérale du prix, du format ou de la qualité des données sans motif valable ;
• imposent un délai de résiliation trop court pour organiser une migration réaliste.

Si tu es le freelance qui conseille le client, ton rôle n’est pas de trancher seul la validité juridique de la clause. Ton rôle est de la repérer, de documenter le risque opérationnel et de recommander une relecture juridique si l’enjeu est important.

Limitation de responsabilité

Une migration peut échouer pour des raisons qui ne dépendent pas de toi : export incomplet fourni par l’éditeur, API instable, données corrompues, absence d’identifiants, historique supprimé avant ton intervention.

Ton contrat doit limiter ta responsabilité aux éléments que tu maîtrises. Il doit aussi prévoir une phase de recette : le client vérifie les données migrées avant coupure de l’ancien outil.

Exemples concrets de missions

Le plus simple est de partir de cas réels. Le Data Act devient lisible quand on le relie à une tâche que tu factures.

Migration Notion vers Airtable

Un client a structuré son suivi opérationnel dans Notion, puis veut passer sur Airtable pour mieux gérer les relations entre tables et automatisations.

À vérifier :

• les bases à exporter ;
• les fichiers et images attachés ;
• les relations entre pages ;
• les historiques nécessaires ;
• les droits d’accès ;
• les automatisations à reconstruire ;
• la suppression des doublons après migration.

Ton livrable peut inclure un plan d’export, un mapping des champs, un rapport d’écarts et une documentation de reprise.

Dashboard Power BI sur données CRM

Tu crées un dashboard Power BI connecté à un CRM. Le client veut suivre pipeline, chiffre d’affaires, taux de conversion et performance commerciale.

On doit cadrer l’accès API, les champs synchronisés, la fréquence de rafraîchissement, les données personnelles visibles, les droits par utilisateur et le sort du dataset Power BI à la fin de la mission.

Si le client change de CRM, pourra-t-il réutiliser ton modèle de reporting ? Devra-t-il payer une refonte complète ? Le contrat doit éviter le flou.

Application SaaS maison

Tu développes un mini-SaaS pour un client : portail client, outil de suivi, plateforme interne, back-office métier.

Ici, la réversibilité doit être pensée dès l’architecture. Prévois un export standard, une documentation des tables, une séparation claire entre données client et code applicatif, et une procédure de suppression.

Si tu héberges l’application toi-même, ajoute une clause de sortie. Le client doit savoir comment récupérer ses données si la collaboration s’arrête.

Pipeline data et stockage cloud

Tu branches des sources multiples vers un entrepôt de données : CRM, outil de facturation, support client, analytics, base produit.

Le risque principal est la dépendance cachée. Le client voit des dashboards, mais ignore les jobs, les connecteurs, les scripts et les transformations.

Un bon plan de réversibilité liste les sources, les destinations, les formats, les secrets, les dépendances cloud, les coûts de sortie et les points de contrôle.

Objet connecté ou service IoT

Tu interviens sur un capteur industriel, un boîtier connecté, une app de maintenance ou une plateforme qui collecte des données de machines.

Le Data Act est particulièrement pertinent, car il vise l’accès aux données générées par les produits connectés et les services associés. À partir du 12 septembre 2026, les nouveaux produits concernés doivent être conçus pour rendre ces données directement accessibles quand c’est possible.

Sur une mission IoT, on documente donc les données générées, leur fréquence, leur format, les droits d’accès, les limites de sécurité et les secrets d’affaires.

Outil IA branché sur une base client

Tu construis un assistant qui interroge une base documentaire client, un CRM ou des tickets support.

On doit distinguer les données d’entrée, les embeddings, les logs de prompts, les réponses générées, les données personnelles, les secrets d’affaires et les données conservées par les fournisseurs IA. Le Data Act pose la question de l’accès et de la réutilisation. Le RGPD pose celle des données personnelles. L’AI Act pose celle du système IA et de ses risques.

Le contrat doit interdire l’utilisation des données client pour d’autres clients, sauf accord explicite. Il doit aussi prévoir comment supprimer l’index, les fichiers temporaires et les logs à la fin de la mission. Si tu veux te spécialiser sur ces missions, le guide devenir consultant IA freelance détaille les profils, les TJM et les clauses à surveiller.

Une architecture data propre n’est pas seulement plus maintenable. Elle rend aussi la sortie possible.

Transformer le Data Act en avantage commercial

On peut subir le Data Act comme une contrainte. Ou on peut en faire une offre claire.

Beaucoup d’entreprises savent qu’elles sont dépendantes de leurs outils, mais elles ne savent pas par où commencer. C’est une excellente zone de mission pour un freelance data, cloud, SaaS, no-code ou IA.

Audit de réversibilité

Tu analyses les outils critiques du client : CRM, ERP, BI, support, facturation, cloud, stockage, automatisations.

Livrables possibles :

• inventaire des données critiques ;
• liste des exports disponibles ;
• test d’export sur un échantillon ;
• analyse des limites API ;
• risques contractuels ;
• dépendances techniques ;
• recommandations de sortie.

Cartographie des données

Tu identifies les données générées, stockées, transformées et transmises. C’est très utile dans les organisations qui ont empilé des outils SaaS sans gouvernance.

Le livrable peut rester simple : schéma des flux, propriétaire de chaque source, outil de destination, fréquence, format, accès et niveau de sensibilité.

Plan d’export et documentation API

Tu aides le client à documenter comment récupérer ses données. C’est une mission courte, mais très utile avant une refonte, un changement d’outil ou une levée de dépendance.

Exemples de livrables :

• procédure d’export ;
• dictionnaire de données ;
• documentation des endpoints API ;
• script de sauvegarde ;
• modèle de fichier cible ;
• contrôle qualité post-export.

Accompagnement migration

La migration reste une prestation à forte valeur : cadrage, extraction, nettoyage, mapping, reprise, tests, recette, formation et arrêt de l’ancien outil.

Le Data Act peut renforcer ton discours commercial, mais ne promets pas une conformité totale. Promets plutôt une méthode : réduire les blocages, documenter les dépendances, vérifier les clauses et sécuriser les exports.

Les pièges à éviter

Le premier piège consiste à confondre données personnelles et données non personnelles. Le Data Act couvre les deux dans certains cas, mais le RGPD reste prioritaire dès qu’une personne est identifiable. Une adresse email, un nom, un identifiant client ou un historique de support peuvent suffire.

Le deuxième piège consiste à promettre une conformité Data Act globale. Un freelance peut auditer, documenter, recommander, migrer ou intégrer. Il ne peut pas garantir seul la conformité d’un éditeur SaaS, d’un fabricant IoT ou d’un fournisseur cloud.

Le troisième piège consiste à ignorer les licences et la propriété intellectuelle. Un export de données peut contenir des éléments protégés : base enrichie, nomenclature propriétaire, documents sous licence, modèles, templates ou secrets d’affaires.

Le quatrième piège consiste à bloquer les exports pour garder le client. C’est mauvais commercialement et de plus en plus risqué juridiquement. La fidélisation doit venir de la qualité de ton travail, pas d’une dépendance subie.

Le cinquième piège consiste à garder une copie client “au cas où”. Sans base contractuelle, durée définie et mesure de sécurité, cette habitude peut devenir un problème. À la fin d’une mission, on restitue, on supprime ou on archive selon ce qui est prévu au contrat.

Ce qui protège le mieux un freelance, ce n’est pas une promesse large. C’est un périmètre précis, documenté et vérifiable.

Checklist avant de signer une mission data, SaaS ou cloud

Avant d’accepter une mission qui touche aux données d’un client, prends 30 minutes pour passer cette checklist.

• Ai-je identifié les données concernées : personnelles, non personnelles, confidentielles, secrets d’affaires ?
• Le client sait-il quels outils SaaS, cloud, IA ou no-code vont traiter les données ?
• Le contrat dit-il qui peut accéder aux données et pour quelle finalité ?
• Un DPA est-il nécessaire au regard du RGPD ?
• Les sous-traitants et outils tiers sont-ils listés ?
• Les formats d’export sont-ils connus et testés ?
• Les pièces jointes, métadonnées, logs et historiques sont-ils inclus ou exclus ?
• Les limites API, quotas, frais de sortie ou délais sont-ils identifiés ?
• La réversibilité est-elle prévue en fin de mission ?
• Le client sait-il ce qui sera supprimé, restitué ou conservé ?
• Les livrables distinguent-ils données client, code, scripts, documentation et méthodes personnelles ?
• La limitation de responsabilité couvre-t-elle les blocages causés par des outils tiers ?
• Une phase de recette est-elle prévue avant suppression ou arrêt de l’ancien système ?
• Les usages IA éventuels sont-ils autorisés et documentés ?
• Le contrat évite-t-il les promesses de conformité totale ?

On peut aussi ajouter une phrase simple dans la proposition commerciale :

La mission inclut une revue opérationnelle des accès, exports et dépendances techniques nécessaires à la réversibilité des données traitées dans le périmètre du projet.

Ce n’est pas une formule magique. Mais elle montre que tu as compris le problème avant qu’il explose.

Conclusion : le Data Act freelance, c’est surtout une méthode

Le Data Act freelance ne doit pas te faire peur. Il doit t’obliger à poser de meilleures questions.

Quand on travaille sur un SaaS, un dashboard, un pipeline data, un outil no-code, une infra cloud ou une IA branchée sur une base client, les données ne sont jamais neutres. Elles ont une valeur, un propriétaire, des droits d’accès, des limites d’usage et un coût de sortie.

La bonne routine est simple : cartographier, contractualiser, documenter, tester l’export, puis prévoir la fin de mission dès le début. C’est plus professionnel. C’est aussi plus vendable.

Et si ton client te dit que “personne n’a jamais demandé ça avant”, tu peux répondre calmement : justement, c’est ce qui évite les mauvaises surprises.

FAQ

Questions fréquentes

Le Data Act concerne-t-il les micro-entrepreneurs ? +

Oui, un micro-entrepreneur peut être concerné s'il intervient sur des données client, un outil SaaS, une migration cloud, un objet connecté, une API ou une prestation data. Le niveau d'obligation dépend du rôle joué : simple prestataire, sous-traitant RGPD, éditeur SaaS, intégrateur ou fournisseur de service.

Faut-il modifier ses CGV à cause du Data Act ? +

Pas toujours, mais il faut relire tes clauses si tu manipules, héberges ou rends accessibles des données client. Les CGV doivent être cohérentes sur la propriété des données, la confidentialité, les outils tiers, la restitution, la suppression, la réversibilité et les limites de responsabilité.

Quelle est la différence entre Data Act et RGPD ? +

Le RGPD protège les données personnelles et les droits des personnes. Le Data Act organise l'accès, le partage et la réutilisation de certaines données, personnelles ou non, notamment dans les objets connectés et les services cloud. Dès qu'une donnée personnelle est en jeu, le RGPD continue de s'appliquer.

Que faire si un client me demande un export de données ? +

Commence par vérifier ton contrat, ton rôle, les données concernées et les outils utilisés. Fournis un export dans un format exploitable si c'est dans ton périmètre, documente les exclusions, protège les données personnelles et garde une trace de la restitution ou de la suppression.

Un freelance qui vend un petit SaaS est-il concerné ? +

Oui, surtout si le SaaS stocke des données métier de clients européens. Il faut prévoir des exports, une documentation minimale, une procédure de sortie, une suppression des données en fin de contrat et des clauses claires sur l'assistance à la migration.

Peut-on facturer une migration malgré le Data Act ? +

Oui. Un freelance peut facturer son travail : audit, extraction, nettoyage, mapping, reprise, tests, documentation et accompagnement. Ce que le Data Act encadre surtout, ce sont les obstacles et frais imposés par certains fournisseurs pour empêcher ou compliquer le changement.

Quelles clauses faut-il éviter dans un contrat SaaS ou data ? +

Évite les clauses qui bloquent les exports, rendent la sortie impossible, autorisent une réutilisation floue des données client, imposent des frais opaques, excluent toute assistance de réversibilité ou mélangent données client, livrables, code et secrets d'affaires sans distinction.