DPA (Data Processing Agreement) pour un backend as a service : ce qu’il doit contenir

Un DPA est le contrat qui encadre juridiquement un fournisseur agissant comme sous-traitant de données personnelles, au sens de l’article 28 du RGPD. Il devient obligatoire dès qu’un responsable de traitement, vous ou votre société, confie le traitement de données personnelles à un tiers. C’est systématiquement le cas avec un backend as a service : comptes utilisateurs, emails, adresses IP, contenu applicatif transitent tous par son infrastructure.

Le DPA n’est pas les conditions générales d’utilisation. Les CGU couvrent la relation commerciale générale : facturation, propriété du contenu, résiliation. Le DPA couvre spécifiquement le traitement de données personnelles, avec des clauses fixées par la loi et non négociables dans leur principe. Leur formulation précise, elle, peut varier d’un fournisseur à l’autre. Un fournisseur qui ne propose que des CGU, sans DPA distinct, ne répond pas à l’exigence de l’article 28.

L’article 28 §3 du RGPD fixe huit obligations que le contrat doit imposer au sous-traitant, de l’instruction documentée jusqu’au droit d’audit du responsable. Ces huit clauses viennent du texte réglementaire lui-même. Un fournisseur ne peut pas les retirer ni les remplacer par une formule plus vague.

Ce qui distingue un DPA réellement opérant d’un modèle copié-collé sans adaptation, c’est la précision avec laquelle chaque clause est remplie, pas leur simple présence dans le sommaire du document.

L’obligation (d) impose une liste nommée de sous-traitants ultérieurs, pas une formule générique du type « nos partenaires techniques ». Le responsable de traitement doit pouvoir identifier chaque tiers qui touche ses données, sa fonction précise et sa localisation.

Le DPA public d’Aurabase liste par exemple six sous-traitants nommés, classés par fonction. L’hébergement infrastructure regroupe Scaleway et Hetzner, deux prestataires basés en UE, avec Mollie (Pays-Bas) pour le paiement. Le SMS d’authentification passe par Twilio (Irlande), les notifications push par Apple et Google, et les certificats TLS par Let’s Encrypt. Tout changement de sous-traitant fait l’objet d’un préavis de 30 jours avec droit d’opposition, tel que documenté sur la page.

Quand un sous-traitant ultérieur traite des données hors UE, le DPA doit référencer une garantie de transfert reconnue, le plus souvent les clauses contractuelles types adoptées par la Commission européenne (décision 2021/914). La nationalité de la société qui héberge ou traite vos données compte aussi, indépendamment de la région choisie, voir notre article sur la nationalité du fournisseur et le CLOUD Act.

L’obligation (e) impose au sous-traitant d’assister le responsable pour répondre aux demandes des personnes concernées : accès, rectification, effacement, portabilité, opposition, limitation. En pratique, cette assistance se mesure à deux choses concrètes : un canal de contact documenté, et un délai de réponse chiffré.

Le RGPD fixe ce délai à un mois pour le responsable de traitement, prolongeable de deux mois pour les demandes complexes (Art. 12 RGPD). Le DPA d’Aurabase reprend ce même délai, environ 30 jours, pour toute demande adressée à privacy@aurabase.cloud. Un export machine-readable reste disponible via la commande CLI aura export --user <email> --format jsonl, pour les demandes d’accès et de portabilité.

Le RGPD distingue deux obligations de notification, souvent confondues. Le responsable de traitement doit notifier l’autorité de contrôle (la CNIL en France) sous 72 heures après avoir eu connaissance d’une violation susceptible d’engendrer un risque pour les personnes (Art. 33 §1). Le sous-traitant, lui, doit notifier le responsable « sans délai injustifié » (Art. 33 §2) : la loi ne fixe aucun chiffre précis pour ce second délai.

C’est là qu’un DPA sérieux ajoute une précision que la loi seule ne fournit pas. Le DPA d’Aurabase s’engage sur un délai de 48 heures maximum pour notifier le responsable, avec un rapport d’incident détaillé sous cinq jours ouvrés. Un DPA qui ne chiffre aucun délai transfère un risque de réactivité que le responsable ne peut pas contrôler lui-même.

L’obligation (g) impose la suppression ou la restitution de toutes les données personnelles à la fin du contrat, au choix du responsable, avec destruction des copies existantes sauf obligation légale de conservation. Cette clause doit préciser un délai concret, pas seulement le principe.

Des durées précises, plutôt qu’une formule du type « dans un délai raisonnable », sont ce qu’il faut chercher dans le DPA d’un fournisseur avant de signer. Une durée non chiffrée complique votre propre preuve de conformité en cas de contrôle.

Cette checklist porte sur le contenu du DPA lui-même. Pour la sélection plus large d’un fournisseur backend conforme (hébergement, société mère, sécurité), voir notre checklist complète de conformité RGPD pour un BaaS.

• Les huit clauses de l’article 28 §3 sont-elles toutes présentes, ou certaines renvoient-elles à un document tiers introuvable ?
• Les sous-traitants ultérieurs sont-ils nommés individuellement, avec leur fonction et leur localisation ?
• Le délai de notification de violation est-il chiffré en heures, ou reste-t-il à « dans les meilleurs délais » ?
• Le sort des données en fin de contrat précise-t-il une durée exacte de suppression, pas seulement le principe ?
• Le DPA référence-t-il des clauses contractuelles types pour tout transfert hors UE identifié dans la liste des sous-traitants ?
• Le document est-il daté, avec une date de dernière mise à jour visible ?