10 min de lecture

API et données personnelles : minimisation, journaux et rétention

DTO publics, pseudonymisation dans les logs, durées de conservation et documentation pour limiter les risques RGPD.

  • API
  • RGPD
  • Sécurité
Schéma : minimisation des données exposées par l’API Moins de champs, moins de risque Modèle interne DTO public / audit

DTO de sortie vs entité Doctrine

L’entité peut contenir email, téléphone, métadonnées internes. Le JSON public doit passer par un DTO ou serializer dédié qui n’expose que les champs prévus par le contrat (OpenAPI).

Journaux et traçabilité

  • Ne pas logger les corps de requête contenant mot de passe, token ou données de santé en clair.
  • Préférer un identifiant technique (UUID utilisateur) aux emails dans les messages d’erreur.
  • Durée de rétention des logs alignée sur la politique interne et le registre des traitements.

Exemple PHP : projection minimale

final class PublicUserView
{
    public function __construct(
        public readonly string $id,
        public readonly string $displayName,
    ) {}
}

// Ne jamais sérialiser User $entity directement en JSON public.

Documentation interne

Listez les endpoints qui traitent des données personnelles, la base légale (contrat, obligation, intérêt légitime…), les sous-traitants (hébergeur, emailing) et les transferts hors UE. Cela aide le DPO et accélère les réponses aux personnes concernées.

FAQ

Le RGPD impose-t-il un format d’API précis ?

Non : il impose des principes (minimisation, sécurité, transparence). La mise en œuvre technique reste à vous, mais les mauvaises pratiques d’exposition et de logs sont souvent relevées en contrôle.

Anonymisation vs pseudonymisation ?

La pseudonymisation réduit le risque mais les données restent personnelles si la ré-identification est possible avec d’autres jeux. L’anonymisation est irréversible — plus rare en API métier vivante.