Data Act et Data Governance Act en pratique

Le Data Act et le Data Governance Act encouragent le partage utile tout en protégeant droits et acteurs. L’objectif est d’industrialiser des partages responsables: rôles clairs, contrats explicites, contrôles continus et preuves d’audit. Ce guide se concentre sur l’état des lieux jusqu’en 2024, sans évoquer d’éléments postérieurs.

chronologie

2022-06-23: DGA entre en vigueur.
2023-09-24: DGA s’applique, notamment pour les intermédiaires et l’altruisme de données.
2024-01-11: Data Act entre en vigueur.

roles

data holder: possède et expose, maintient le catalogue, applique IAM et filtrage ligne/colonne.
data user: consomme selon contrat, respecte la finalité, ne détourne pas l’usage.
intermediaire: facilite l’accès, vérifie les règles, trace les décisions.
autorite: contrôle la mise en oeuvre, peut solliciter les preuves.

contrats et acces

Un contrat doit être court, diffusable et vérifiable.

objet: quelles données, versions, unités, cadence.
finalite: autorisée, interdite, durée.
securite: chiffrement, IAM, RLS/CLS.
conservation: délais producteur et consommateur.
audit: journaux, formats, rétention.

contract:
  id: "telemetrie_appareils_v1:eu-west-1"
  dataset: "telemetrie_appareils_v1"
  version: "1.2.0"
  owner: "@iot-platform"
  purpose_allow: ["maintenance preventive", "qualite service"]
  purpose_deny: ["profilage marketing", "revente brute"]
  access_methods: ["api", "export parquet"]
  pii: "masquee"
  rls: "device_owner_id = :consumer_account_id"
  retention_producer_days: 365
  retention_consumer_days: 180
  audit_trail: "governance.access_log"
  contacts:
    security: "sec@exemple.com"
    data_steward: "data@exemple.com"

processus de demande d’acces

gouverner la reutilisation

catalogue des partages et des finalités approuvées.
évaluation courte des risques avant chaque nouveau partage.
comité de réutilisation mensuel: incidents, exceptions, volumes.
plan de dépréciation quand le schéma change.

modeles de controles

rls ligne et cls colonne

-- politique RLS: restreindre aux appareils du consommateur
CREATE POLICY rls_device_owner
ON iot.telemetrie_appareils
AS PERMISSIVE
FOR SELECT
TO role_consommateur
USING (device_owner_id = current_setting('app.consumer_account_id')::text);

-- CLS simple via vue masquees
CREATE OR REPLACE VIEW iot.telemetrie_appareils_v1 AS
SELECT
  device_id,
  reading_ts,
  CASE WHEN has_privilege('see_raw_email') THEN owner_email ELSE 'masked' END AS owner_email,
  CASE WHEN has_privilege('see_raw_location') THEN gps_lat ELSE round(gps_lat::numeric, 2) END AS gps_lat,
  CASE WHEN has_privilege('see_raw_location') THEN gps_lon ELSE round(gps_lon::numeric, 2) END AS gps_lon,
  temperature_c,
  voltage_v
FROM iot.telemetrie_appareils_raw;

journal d’acces minimal

CREATE TABLE IF NOT EXISTS governance.access_log (
  event_id         UUID PRIMARY KEY,
  happened_at      TIMESTAMP NOT NULL,
  actor_principal  TEXT NOT NULL,
  dataset          TEXT NOT NULL,
  contract_id      TEXT NOT NULL,
  action           TEXT CHECK (action IN ('read','export','revoke','rotate')),
  rows_read        BIGINT,
  purpose          TEXT,
  decision         TEXT CHECK (decision IN ('allow','deny')),
  reason           TEXT
);

verification de schema et versions

-- table de reference des versions
CREATE TABLE IF NOT EXISTS governance.schema_registry (
  dataset TEXT,
  version TEXT,
  schema_hash TEXT,
  released_at TIMESTAMP,
  PRIMARY KEY(dataset, version)
);

-- check de compatibilite lors d'un changement
-- (pseudo-code SQL, adaptez aux fonctions disponibles)

evaluation rapide des risques

nature: PII, données sensibles, agrégations.
transferts: hors UE, sous-traitants concernés.
volumetrie: transactionnel vs export massif.
finalite: utile, proportionnée, non détournée.
mesures: chiffrement, RLS/CLS, masquage, rotation des clés.

risk_check:
  pii: "faible"
  transfers_extra_eu: "non"
  volumes: "moyens"
  purpose_ok: true
  mitigations: ["masquage", "rls", "chiffrement au repos"]
  reviewer: "@governance"
  reviewed_at: "2024-04-14"

cas d’usage

b2b maintenance preventive

holder: fabricant d’appareils.
user: prestataire de maintenance.
finalite: prédire pannes, planifier interventions.
limites: pas d’usage marketing, pas de revente des flux bruts.

b2g situation exceptionnelle

accès du secteur public aux données privées dans des cas stricts, nécessaires et proportionnés.
prévoir un canal dédié, des journaux détaillés, une révision post-incident.

b2g_channel:
  trigger: "situation exceptionnelle documentee"
  scope: "liste delimitee de champs et de dates"
  approval: ["legal", "security", "exec"]
  logging: "granulaire, exportable"
  review_window_days: 30

interoperabilite et portabilite

schémas sémantiques stables, versions semver.
formats ouverts: parquet, jsonl, csv avec dictionnaire.
endpoints cohérents: listing, lecture par clé, pagination, filtres.
export programmatique et retrait global.

schema_registry:
  dataset: "telemetrie_appareils"
  versions:
    - "1.1.0"
    - "1.2.0"
  fields:
    - name: "device_id"
      type: "string"
      desc: "identifiant stable"
    - name: "reading_ts"
      type: "timestamp"
      desc: "horodatage utc"
    - name: "temperature_c"
      type: "float"
      desc: "temperature en celsius"

quotas et throttling

Mettez des garde-fous explicites et traçables.

-- quotas par contrat et par jour
CREATE TABLE IF NOT EXISTS governance.contract_quota (
  contract_id TEXT,
  period      DATE,
  rows_limit  BIGINT,
  rows_used   BIGINT DEFAULT 0,
  PRIMARY KEY (contract_id, period)
);

-- verification avant export
CREATE OR REPLACE FUNCTION governance.check_quota(p_contract TEXT, p_rows BIGINT)
RETURNS BOOLEAN AS $$
DECLARE
  rec governance.contract_quota;
BEGIN
  SELECT * INTO rec FROM governance.contract_quota
  WHERE contract_id = p_contract AND period = current_date;
  IF NOT FOUND THEN
    INSERT INTO governance.contract_quota(contract_id, period, rows_limit, rows_used)
    VALUES (p_contract, current_date, 1000000, 0)
    RETURNING * INTO rec;
  END IF;
  IF rec.rows_used + p_rows > rec.rows_limit THEN
    RETURN FALSE;
  END IF;
  UPDATE governance.contract_quota
    SET rows_used = rows_used + p_rows
  WHERE contract_id = p_contract AND period = current_date;
  RETURN TRUE;
END;
$$ LANGUAGE plpgsql;

exceptions controlees

exception motivée, datée, limitée en portée.
revue périodique et traçabilité complète.

exception:
  id: "ex-2024-04-20-001"
  policy_target: "telemetrie_appareils_v1#rls"
  granted_to: "@partner-maintenance"
  reason: "investigation incident capteur lot A"
  scope: "10 devices sur 7 jours"
  expires_at: "2024-04-27"
  reviewer: "@security"

supervision

Suivez quelques métriques simples pour piloter.

délai d’attribution des accès.
taux de demandes rejetées pour finalité floue.
incidents liés à versioning ou schéma.
fraîcheur et latence livrées vs SLA.
écarts d’usage vs contrat.

modele d’api

Exposez des endpoints cohérents et simples.

GET /api/v1/datasets/telemetrie_appareils_v1/readings?device_id=...&from=...&to=...
Authorization: Bearer <token>

200 OK
Content-Type: application/json
{
  "contract_id": "telemetrie_appareils_v1:eu-west-1",
  "rows": [
    {"device_id":"A42","reading_ts":"2024-04-14T10:00:00Z","temperature_c":21.0,"voltage_v":3.7},
    {"device_id":"A42","reading_ts":"2024-04-14T10:05:00Z","temperature_c":21.2,"voltage_v":3.7}
  ],
  "next": null
}

pipeline conformite et preuves

Construisez un pipeline qui produit naturellement les preuves.

publication catalogue

une page par dataset avec versions, finalités, SLA, contacts.
un point d’accès machine lisible pour automatiser.

{
  "dataset": "telemetrie_appareils_v1",
  "version": "1.2.0",
  "owner": "@iot-platform",
  "purpose_allow": ["maintenance preventive", "qualite service"],
  "access_methods": ["api", "export parquet"],
  "pii": "masquee",
  "sla": {"availability": "99.5%", "freshness_max": "PT6H"}
}

offboarding et retrait

Quand un contrat prend fin, la révocation doit être simple, traçable et attestée.

checklists

contrat: complet, versionné, diffusé.
finalité: claire, limitée, pertinente.
sécurité: IAM, RLS/CLS, masquage, chiffrement.
audit: journaux immuables, exports prêts.
migration: notes, double publication, dates.
exceptions: datées, motivées, revues.

readiness_check:
  contract_ready: true
  purpose_clear: true
  security_controls: ["iam","rls","cls","masking","encryption"]
  audit_ready: true
  migration_plan: "ok"
  exceptions_policy: "ok"

erreurs courantes

clauses floues -> litiges -> gabarits clairs et listes allow et deny
versions sauvages -> casse en prod -> semver et double publication
exceptions permanentes -> derive -> expiration obligatoire et revue périodique
absence de journaux -> preuve impossible -> access_log normalisé et exportable
sur-collecte -> risques inutiles -> limiter champs, filtrer tôt, agréger quand possible

Menu

Data Act et Data Governance Act en pratique

Data Act et Data Governance Act en pratique

chronologie

roles

contrats et acces

processus de demande d’acces

gouverner la reutilisation

modeles de controles

rls ligne et cls colonne

journal d’acces minimal

verification de schema et versions

evaluation rapide des risques

cas d’usage

b2b maintenance preventive

b2g situation exceptionnelle

interoperabilite et portabilite

quotas et throttling

exceptions controlees

supervision

modele d’api

pipeline conformite et preuves

publication catalogue

offboarding et retrait

checklists

erreurs courantes

tags