GDPR pour les developpeurs | Ce que vous devez vraiment implementer

Le GDPR est en vigueur depuis 2018, mais la plupart des guides pour developpeurs se concentrent encore sur la theorie juridique. Ce guide est different. Il couvre les exigences techniques, le code que vous devez ecrire et les decisions architecturales qui rendent la conformite pratique plutot que penible.

Si votre logiciel stocke, traite ou touche des donnees personnelles de personnes dans l’UE, cela vous concerne. Peu importe ou votre entreprise est basee.

GDPR en bref pour les developpeurs

Passez les 99 articles. Voici ce que le GDPR signifie pour votre code :

1. Ne collectez que ce dont vous avez besoin. Ne stockez pas de donnees “au cas ou.”
2. Dites aux utilisateurs ce que vous faites avec leurs donnees. Et obtenez leur permission quand c’est requis.
3. Permettez aux utilisateurs d’acceder a leurs donnees, de les exporter et de les supprimer. Vous avez besoin d’endpoints API pour cela.
4. Gardez les donnees en securite. Chiffrement, controles d’acces, journaux d’audit.
5. Signalez les violations rapidement. Vous avez 72 heures pour notifier les autorites apres avoir decouvert une violation.
6. Documentez tout. Vos activites de traitement, vos mesures de securite, vos flux de donnees.

C’est le resume pratique. Le reste de ce guide vous montre comment implementer chaque exigence.

Les 7 exigences techniques cles

1. Gestion du consentement

Le consentement doit etre librement donne, specifique, eclaire et sans ambiguite. Les cases precochees ne comptent pas. Le consentement groupe (“accepter tout”) ne compte pas. Le retrait doit etre aussi facile que l’octroi du consentement.

Quoi construire

Un systeme de consentement necessite trois composants :

• Un registre de consentement. Pour chaque utilisateur, suivez ce a quoi il a consenti, quand et comment.
• Un mecanisme de verification du consentement. Avant de traiter des donnees pour un objectif specifique, verifiez que l’utilisateur a un consentement actif.
• Un mecanisme de retrait. Permettez aux utilisateurs de revoquer le consentement via votre interface, et arretez le traitement immediatement.

Schema de base de donnees

CREATE TABLE user_consents (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id UUID NOT NULL REFERENCES users(id),
  consent_type VARCHAR(100) NOT NULL,
  granted BOOLEAN NOT NULL,
  granted_at TIMESTAMPTZ,
  revoked_at TIMESTAMPTZ,
  ip_address INET,
  user_agent TEXT,
  created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

CREATE INDEX idx_user_consents_lookup
  ON user_consents (user_id, consent_type, granted);

Stockez l’historique complet. Ne supprimez et n’ecrasez jamais les enregistrements de consentement. Quand un utilisateur revoque son consentement, inserez une nouvelle ligne avec granted = false et renseignez revoked_at. Cela vous donne une piste d’audit.

Middleware de verification du consentement

Voici un middleware Express qui verifie le consentement avant de traiter une requete :

import { Request, Response, NextFunction } from "express";
import { db } from "./database";

interface ConsentRequirement {
  type: string;
  required: boolean;
}

function requireConsent(consentType: string) {
  return async (req: Request, res: Response, next: NextFunction) => {
    const userId = req.user?.id;

    if (!userId) {
      return res.status(401).json({ error: "Authentication required" });
    }

    const consent = await db.query(
      `SELECT granted FROM user_consents
       WHERE user_id = $1 AND consent_type = $2
       ORDER BY created_at DESC
       LIMIT 1`,
      [userId, consentType]
    );

    if (!consent.rows[0]?.granted) {
      return res.status(403).json({
        error: "Consent required",
        consentType,
        message: `You must grant "${consentType}" consent to use this feature.`,
        consentUrl: `/settings/privacy`,
      });
    }

    next();
  };
}

// Usage
app.post(
  "/api/newsletter/subscribe",
  requireConsent("marketing_emails"),
  subscribeHandler
);

app.post(
  "/api/analytics/track",
  requireConsent("usage_analytics"),
  trackHandler
);

2. Acces et export des donnees (Droit d’acces)

Les utilisateurs ont le droit de demander une copie de toutes les donnees personnelles que vous detenez a leur sujet. Vous devez les fournir dans un format couramment utilise et lisible par machine. JSON ou CSV convient.

Quoi construire

Un endpoint qui collecte toutes les donnees personnelles d’un utilisateur a travers chaque table et service, puis les emballe dans un fichier telechargeable.

interface DataExport {
  exportedAt: string;
  user: {
    profile: Record<string, unknown>;
    activity: Record<string, unknown>[];
    consents: Record<string, unknown>[];
    communications: Record<string, unknown>[];
  };
}

app.get("/api/me/data-export", authenticate, async (req, res) => {
  const userId = req.user.id;

  const [profile, activity, consents, communications] = await Promise.all([
    db.query("SELECT id, email, name, created_at FROM users WHERE id = $1", [
      userId,
    ]),
    db.query(
      "SELECT action, metadata, created_at FROM user_activity WHERE user_id = $1 ORDER BY created_at DESC",
      [userId]
    ),
    db.query(
      "SELECT consent_type, granted, granted_at, revoked_at FROM user_consents WHERE user_id = $1 ORDER BY created_at DESC",
      [userId]
    ),
    db.query(
      "SELECT type, sent_at, subject FROM communications WHERE user_id = $1 ORDER BY sent_at DESC",
      [userId]
    ),
  ]);

  const exportData: DataExport = {
    exportedAt: new Date().toISOString(),
    user: {
      profile: profile.rows[0],
      activity: activity.rows,
      consents: consents.rows,
      communications: communications.rows,
    },
  };

  res.setHeader("Content-Type", "application/json");
  res.setHeader(
    "Content-Disposition",
    `attachment; filename="data-export-${userId}.json"`
  );
  res.json(exportData);
});

Cet endpoint doit couvrir chaque table contenant des donnees utilisateur. Auditez votre schema en profondeur. Une table manquante signifie un export incomplet, ce qui est un manquement a la conformite.

3. Droit a la suppression (Droit a l’oubli)

Les utilisateurs peuvent demander que vous supprimiez toutes leurs donnees personnelles. Vous devez vous conformer sauf si vous avez une obligation legale de les conserver (comme les registres fiscaux ou la prevention de la fraude).

Quoi construire

Un endpoint de suppression qui supprime ou anonymise les donnees utilisateur a travers toutes les tables. C’est plus difficile qu’il n’y parait a cause des contraintes de cles etrangeres et des donnees dont d’autres systemes dependent.

app.delete("/api/me/account", authenticate, async (req, res) => {
  const userId = req.user.id;
  const client = await db.getClient();

  try {
    await client.query("BEGIN");

    // Anonymiser les donnees qui doivent etre conservees pour les registres commerciaux
    await client.query(
      `UPDATE orders
       SET customer_name = 'deleted', customer_email = 'deleted'
       WHERE user_id = $1`,
      [userId]
    );

    // Supprimer les donnees qui peuvent etre entierement retirees
    await client.query("DELETE FROM user_activity WHERE user_id = $1", [
      userId,
    ]);
    await client.query("DELETE FROM user_consents WHERE user_id = $1", [
      userId,
    ]);
    await client.query("DELETE FROM communications WHERE user_id = $1", [
      userId,
    ]);
    await client.query("DELETE FROM sessions WHERE user_id = $1", [userId]);

    // Anonymiser l'enregistrement utilisateur au lieu de le supprimer
    // Cela preserve l'integrite referentielle
    await client.query(
      `UPDATE users SET
        email = 'deleted-' || id || '@removed.invalid',
        name = 'Deleted User',
        phone = NULL,
        address = NULL,
        deleted_at = NOW()
       WHERE id = $1`,
      [userId]
    );

    await client.query("COMMIT");

    // Declencher la suppression dans les systemes externes
    await Promise.allSettled([
      emailService.deleteSubscriber(userId),
      analyticsService.deleteUser(userId),
      searchIndex.removeUser(userId),
    ]);

    res.json({ message: "Account and personal data deleted" });
  } catch (error) {
    await client.query("ROLLBACK");
    throw error;
  } finally {
    client.release();
  }
});

Decisions cles :

• Supprimer vs anonymiser. Les enregistrements necessaires pour la comptabilite (commandes, factures) doivent etre anonymises. Supprimez tout le reste.
• Systemes externes. Les donnees envoyees a des services tiers doivent aussi y etre supprimees.
• Delai. Le GDPR dit “sans retard excessif.” Completez la suppression sous 30 jours. Pour la plupart des systemes, faites-la immediatement.

4. Minimisation des donnees

Ne collectez et ne stockez que les donnees dont vous avez reellement besoin pour un objectif declare. Si vous demandez un numero de telephone mais n’appelez jamais les utilisateurs, vous ne devriez pas le collecter.

Regles pratiques

• Auditez chaque champ de formulaire. Pour chaque champ, demandez : “Quelle fonctionnalite specifique ne marche plus si on le supprime ?” Si la reponse est rien, supprimez-le.
• Definissez des periodes de conservation. Ne gardez pas les donnees eternellement. Definissez combien de temps chaque type de donnee est necessaire, puis supprimez-le automatiquement.
• Minimisez le logging. Retirez les donnees personnelles des entrees de log. Journalisez les identifiants utilisateur, pas les noms ni les emails.

-- Conservation automatique des donnees avec PostgreSQL
-- Executez ceci en tache planifiee (ex. pg_cron)
DELETE FROM user_activity
WHERE created_at < NOW() - INTERVAL '2 years';

DELETE FROM session_logs
WHERE created_at < NOW() - INTERVAL '90 days';

DELETE FROM password_reset_tokens
WHERE created_at < NOW() - INTERVAL '24 hours';

5. Chiffrement

Le GDPR exige des “mesures techniques appropriees” pour proteger les donnees personnelles. Le chiffrement est la plus importante.

Au repos

• Chiffrez le disque de votre base de donnees. Tous les principaux fournisseurs cloud le supportent. Activez-le et verifiez.
• Pour les champs hautement sensibles (numeros de securite sociale, donnees de sante), ajoutez un chiffrement au niveau applicatif en plus.
• Chiffrez les sauvegardes. Une sauvegarde non chiffree est une violation en attente.

En transit

• TLS partout. Chaque connexion entre les services, les bases de donnees et les utilisateurs. Sans exception.
• Forcez HTTPS. Redirigez HTTP. Definissez les en-tetes HSTS.
• Utilisez TLS pour les connexions a la base de donnees. PostgreSQL le supporte nativement.

// Connexion PostgreSQL avec TLS
import { Pool } from "pg";

const pool = new Pool({
  host: process.env.DB_HOST,
  port: 5432,
  database: process.env.DB_NAME,
  user: process.env.DB_USER,
  password: process.env.DB_PASSWORD,
  ssl: {
    rejectUnauthorized: true,
    ca: fs.readFileSync("/path/to/server-ca.pem").toString(),
  },
});

6. Notification de violation

Si des donnees personnelles sont compromises, vous devez notifier l’Autorite de Protection des Donnees competente dans les 72 heures. Si la violation presente un risque eleve pour les individus, vous devez aussi notifier les utilisateurs concernes.

Quoi construire

• Journalisation d’audit. Suivez chaque acces aux donnees personnelles. Qui y a accede, quand et d’ou.
• Detection d’anomalies. Alertez sur les schemas d’acces inhabituels (exports massifs de donnees, acces depuis de nouvelles IP, acces en dehors des heures de bureau).
• Un plan de reponse aux incidents. Documentez qui fait quoi quand une violation est detectee. Ce n’est pas du code. C’est une checklist que votre equipe pratique.

CREATE TABLE data_access_log (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id UUID NOT NULL,
  accessed_by UUID NOT NULL,
  access_type VARCHAR(50) NOT NULL,
  resource_type VARCHAR(100) NOT NULL,
  resource_id UUID,
  ip_address INET,
  user_agent TEXT,
  created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

CREATE INDEX idx_data_access_log_user
  ON data_access_log (user_id, created_at);

CREATE INDEX idx_data_access_log_accessor
  ON data_access_log (accessed_by, created_at);

7. Protection des donnees des la conception

Le GDPR dit que la vie privee doit etre integree aux systemes des le depart, pas ajoutee apres coup. En pratique, cela signifie faire de la vie privee le choix par defaut.

• Prive par defaut. Les nouvelles fonctionnalites doivent collecter un minimum de donnees et exiger un opt-in pour tout ce qui depasse la fonction principale.
• Les parametres sont regles sur l’option la plus privee par defaut. Les utilisateurs qui ne touchent jamais a leurs parametres doivent avoir la protection de vie privee la plus elevee.
• Separez les preoccupations. Ne melangez pas les donnees analytiques avec les donnees fonctionnelles. Ne reutilisez pas les tokens d’authentification pour le tracking.

Anonymisation vs pseudonymisation

Ce n’est pas la meme chose, et la distinction compte.

• La pseudonymisation remplace les informations identifiantes par un token reversible. Exemple : hachage des adresses email. Si vous avez la fonction de hachage et l’email original, vous pouvez re-identifier la personne. Le GDPR s’applique toujours car la re-identification est possible.
• L’anonymisation supprime les informations identifiantes de facon permanente. Exemple : analyses agreges (“1 247 utilisateurs ont visite la page tarifs”) sans aucun moyen d’identifier quels utilisateurs. Le GDPR ne s’applique pas aux donnees veritablement anonymisees.

La vraie anonymisation est difficile. Si votre jeu de donnees “anonyme” inclut un horodatage, une ville et un type d’appareil, cette combinaison pourrait identifier quelqu’un de facon unique. Soyez prudent.

Consentement aux cookies

Si votre site web utilise des cookies au-dela de ce qui est strictement necessaire, vous avez besoin du consentement avant de les deposer.

Necessite un consentement : cookies d’analyse, pixels publicitaires, widgets de reseaux sociaux, tout script de tracking tiers.

Ne necessite pas de consentement : cookies de session, cookies de panier d’achat, tokens CSRF, le cookie de preference de consentement lui-meme.

Votre banniere de consentement doit bloquer les cookies non essentiels jusqu’a ce que le consentement soit donne, offrir des choix granulaires et rendre “Tout refuser” aussi facile que “Tout accepter.” Ne construisez pas cela de zero. Des outils comme Cookiebot gerent la complexite. La regle cle : aucun script de tracking ne se declenche avant que le consentement ne soit accorde.

Sous-traitants de donnees tiers

Chaque service tiers qui traite les donnees de vos utilisateurs est un “sous-traitant” au sens du GDPR. Vous etes responsable de leur conformite.

Quoi verifier

Avant d’integrer tout service tiers qui touche des donnees personnelles :

1. Ont-ils un DPA ? Un accord de traitement des donnees est obligatoire. La plupart des fournisseurs SaaS publient le leur publiquement.
2. Ou stockent-ils les donnees ? Si hors de l’UE, verifiez la base legale du transfert.
3. A quelles donnees ont-ils acces ? Minimisez ce que vous envoyez. Si le service n’a besoin que d’un email, n’envoyez pas le profil complet.
4. Pouvez-vous supprimer les donnees de leurs systemes ? Les demandes de suppression utilisateur doivent se propager partout.
5. Comment gerent-ils les violations ? Leur DPA doit specifier les delais de notification.

Sous-traitants tiers courants a examiner

• Services email (Resend, SendGrid, Mailchimp)
• Analytics (Google Analytics, Mixpanel, Amplitude)
• Suivi d’erreurs (Sentry, Bugsnag)
• Traitement des paiements (Stripe, Adyen)
• Hebergement cloud (AWS, Google Cloud, Vercel)
• Outils de support client (Intercom, Zendesk)
• API d’IA (OpenAI, Anthropic, Google AI)

Maintenez une liste de tous les sous-traitants. Revisez-la trimestriellement.

Politiques de conservation des donnees

Ne gardez pas les donnees personnelles plus longtemps que necessaire. Definissez des periodes de conservation pour chaque type de donnee.

Type de donnee	Conservation suggeree	Raison
Donnees de compte utilisateur	Jusqu’a demande de suppression	Necessaire pour le service
Journaux de session	90 jours	Securite et debogage
Journaux d’activite utilisateur	1 a 2 ans	Analyse produit
Tickets de support	3 ans	Qualite de service
Registres financiers	7 ans	Obligations fiscales/legales
Tokens de reinitialisation de mot de passe	24 heures	Securite
Tentatives de connexion echouees	90 jours	Surveillance de securite

Implementez des taches de nettoyage automatisees. Ne comptez pas sur quelqu’un qui se souvienne d’executer un script.

Checklist GDPR pour les developpeurs

Utilisez ceci comme point de depart pour construire ou auditer un systeme.

Collecte des donnees

• Chaque champ de formulaire a un objectif declare
• Aucune donnee inutile n’est collectee
• La politique de confidentialite est liee a chaque point de collecte de donnees
• Le consentement est collecte avant le traitement (quand requis)
• Les enregistrements de consentement sont stockes avec horodatage

Stockage des donnees

• Le chiffrement au repos de la base de donnees est active
• TLS est applique pour toutes les connexions
• Les champs sensibles ont un chiffrement au niveau applicatif
• Les sauvegardes sont chiffrees
• L’acces aux donnees de production est restreint et journalise

Droits des utilisateurs

• Un endpoint d’export de donnees existe et couvre toutes les tables
• Un endpoint de suppression de compte existe et gere toutes les donnees
• Les utilisateurs peuvent consulter et retirer leur consentement dans leurs parametres
• La suppression se propage aux services tiers
• Toutes les demandes de droits utilisateur recoivent une reponse sous 30 jours

Cookies et tracking

• Une banniere de consentement aux cookies est implementee
• Les cookies non essentiels sont bloques avant consentement
• Les choix de consentement sont granulaires (pas tout ou rien)
• “Tout refuser” est aussi visible que “Tout accepter”

Tiers

• Tous les sous-traitants de donnees sont documentes
• Des DPA sont signes avec chaque sous-traitant
• Les donnees envoyees aux tiers sont minimisees
• La suppression des donnees chez les tiers est possible

Securite

• Les journaux d’audit suivent l’acces aux donnees personnelles
• L’alerte d’anomalies est configuree
• Le plan de reponse aux incidents est documente
• Le processus de notification de violation est defini (delai de 72 heures)

Conservation

• Les periodes de conservation sont definies pour tous les types de donnees
• Les taches de nettoyage automatisees sont planifiees
• Les donnees expirees sont reellement supprimees (verifiez cela)

Reflexions finales

La conformite GDPR n’est pas un projet ponctuel. C’est un ensemble de pratiques integrees dans la facon dont vous construisez des logiciels. Le travail technique est simple : stockage du consentement, export de donnees, endpoints de suppression, chiffrement, journalisation d’audit. De l’ingenierie standard.

La partie difficile est d’etre exhaustif. Il est facile d’oublier ce fichier log, cet evenement analytics ou cette integration tierce qui stocke les emails des utilisateurs. Auditez regulierement. Testez votre endpoint de suppression. Verifiez que vos exports sont complets. Integrez la vie privee dans votre processus des le debut.

---

Besoin d’aide pour construire un logiciel conforme au GDPR ou auditer vos systemes existants ? Contactez-nous. Nous construisons des applications axees sur la vie privee pour les entreprises europeennes et les societes servant des utilisateurs dans l’UE.